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The  development  of  a  complex  object-oriented  software  system  is  a  costly  en- 
deavor. Prototypes  would  not  be  "throw-aways"  and  much  time  and  effort  could  be 
saved  if  a  complex  software  system  were  developed  by  a  series  of  refined  and  veri- 
fied prototypes  as  the  prototyper  gains  more  and  more  knowledge  about  the  func- 
tionality and  performance  requirements  of  the  system  being  developed.  To  support 
such  an  evolutionary  prototyping  process,  a  powerful  knowledge  base  management 
system  (KBMS)  has  been  developed  in  this  work  to  provide:  1)  a  powerful  object 
model  for  modeling  the  structural  and  behavioral  properties  and  constraints  of  soft- 
ware components  and  the  data  entities  they  manipulate,  in  a  uniform  manner,  2) 
a  persistent  knowledge  base  (KB)  to  maintain  the  models  of  these  prototypes  and 
the  data  related  to  design  decision,  requirements,  schedules,  milestones,  etc.,  3)  a 
knowledge  base  programming  language  for  querying  and  manipulating  the  persistent 


knowledge  base,  as  well  as  for  writing  code,  and  4)  a  prototyping  environment  to 
support  the  functionality  tracing  and  performance  evaluation  of  the  target  system. 
The  existing  debuggers  and  profilers  provide  support  for  object-oriented  software  sys- 
tem evaluation  using  a  tracing  mechanism,  which  allows  a  system  analyst  to  follow 
the  program  execution  step  by  step,  and  to  stop  at  any  particular  point  of  execu- 
tion so  that  visible  variables  can  be  observed  and  evaluated.  However,  the  execution 
profile  data  are  not  stored  in  a  persistent  store  nor  managed  by  an  intelligent  data 
management  system  to  support  the  analysis  of  the  profiling  data  and  to  derive  more 
useful  information  about  the  system  behavior.  In  this  work,  we  use  Event-Condition- 
Action- Alternative- Action  (ECAA)  rules  to  specify  points  of  system  monitoring  and 
antecedent-consequent  rules  for  behavior  abstraction  and  analysis.  The  implemented 
KBMS  is  used  to  manage  execution  profile  data  and  to  process  both  types  of  rules 
to  support  system  monitoring  and  analysis. 


CHAPTER  1 
INTRODUCTION 


The  development  of  a  complex  software  system  is  a  costly  and  time-consuming 
process.  In  the  traditional  prototyping  approach  a  prototype  of  the  target  system 
is  developed  for  the  purpose  of  gaining  a  better  understanding  of  the  users'  require- 
ments. It  is  used  to  help  the  developers  to  remove  misunderstandings  between  them- 
selves and  the  users  and  to  verify  with  the  users  their  expected  system  functionalities. 
The  prototype  is  then  thrown  away  and  the  target  system  is  developed  from  scratch, 
based  on  the  experience  and  knowledge  gained  during  the  prototyping  process.  Us- 
ing this  approach,  much  of  the  efforts  of  the  prototype  development  phase  is  wasted. 
Sometimes  the  cost  of  prototype  development  represents  an  unacceptably  large  por- 
tion of  the  total  system  development  cost.  Similarly,  the  traditional  "waterfall"  soft- 
ware life  cycle  serves  little  but  to  exacerbate  the  problems  of  software  development 
and  maintenance  by  delaying  the  discovery  of  incorrect  or  inappropriate  specifications 
and  requirements  until  the  testing  phase  that  follows  the  implementation  phase.  The 
cost  and  time  can  be  greatly  reduced  if  systems  can  be  developed  through  a  series 
of  evolving,  executable,  and  evaluable  prototypes,  as  the  prototyper  gains  more  and 
more  knowledge  about  the  functional  and  performance  requirements  of  those  systems 
being  developed.    In  the  evolutionary  prototyping  process  the  conceptual  model  of 


the  prototype  system  is  gradually  modified  and  extended,  as  more  and  more  knowl- 
edge about  the  system  requirements  are  identified  until  the  final  system  is  developed. 
In  this  process,  the  prototyper  first  develops  a  initial  prototype  based  on  his/her 
knowledge  of  the  system  requirements  and  then  evaluates  the  initial  prototype  to  see 
whether  its  functionality  and  performance  meet  the  desired  requirements.  If  the  re- 
quirements are  not  met,  then  he/she  would  modify  the  design  and  re- test  the  refined 
prototype.  The  cycle  would  repeat  until  the  target  system  is  developed  and  evaluated 
[Bal82].  In  other  words,  each  prototype  system  can  be  thought  of  as  an  executable 
model  of  the  target  system.  The  model  can  gradually  evolve  into  the  target  system 
as  more  and  more  details  are  specified  in  it.  All  the  testing,  debugging,  modifica- 
tion, and  maintenance  can  be  performed  directly  against  the  executable  models.  The 
executions  of  the  evolving  prototypes  allow  errors  and  design  misconceptions  to  be 
identified  in  various  stages  of  the  prototyping  effort,  thus  allowing  a  complex  system 
to  developed  much  faster  and  at  a  lower  cost. 

To  support  such  an  evolutionary  prototyping  process,  it  is  useful  to  have  a  pow- 
erful knowledge  base  management  system  (KBMS)  to  provide:  1)  a  powerful  object 
model  for  modeling  the  structural  and  behavioral  properties  and  the  constraints  of 
the  software  components  that  constitute  the  evolving  prototypes  and  the  data  they 
manipulate  in  a  uniform  manner,  2)  a  persistent  knowledge  base  to  maintain  the 
models  of  these  prototypes  and  the  data  related  to  design  decision,  requirements, 
schedules,  milestones,  etc.,  3)  a  querying  facility  to  allow  ad  hoc  inquiries  about  the 
prototype  system  and  the  data  gathered  about  it.    When  modifications  are  made 


to  a  prototype,  consistency  checking  and  integrity  enforcement  need  to  be  carried 
out.  So,  in  addition  to  the  above  features,  a  KBMS  needs  to  have  a  knowledge  rule 
specification  and  processing  capability.  This  is  because  the  structure  and  behavior 
of  a  complex  system  are  often  subjected  to  design,  operational,  and  system  rules  and 
constraints.  If  these  rules  are  explicitly  specified  in  the  model  of  a  prototyping  sys- 
tem, then  they  can  be  used  by  a  KBMS  to  automatically  maintain  system  constraints 
and/or  activate  operations  when  certain  events  occur.  Although  the  semantics  rep- 
resented by  rules  can  be  implemented  in  methods,  high-level  declarative  rules  make 
it  much  easier  for  a  prototyper  to  clearly  capture  different  semantic  properties,  and 
thus  simplify  the  task  of  implementation,  debugging,  and  maintenance.  For  example, 
rules  can  be  used  to  dynamically  modify  the  control  flow  between  methods  without 
affecting  the  application  code,  thus  improving  the  modularity  of  the  system  [Day90]. 
They  can  be  used  both  during  the  development  phase  as  well  as  in  the  evaluation 
phase  of  the  target  system.  The  details  will  be  discussed  later  in  this  dissertation. 

In  addition  to  a  KBMS,  we  need  a  knowledge  base  programming  language  for 
querying  and  manipulating  the  persistent  knowledge  base  as  well  as  for  writing  code. 
We  also  need  to  provide  the  prototype  a  prototyping  environment  with  monitoring 
and  profiling  tools  to  carry  out  the  following  functions:  1)  tracing  the  execution 
of  a  prototype  at  any  stage  of  development,  2)  generating  the  information  about 
time  taken  to  execute  different  parts  of  a  prototype,  3)  monitoring  a  prototype  be- 
havior at  run-time  and  4)  inferring  on  the  monitored  data  to  analyze  a  prototype 
behavior  and  understand  the  problems  and  bottlenecks  in  the  prototype  in  various 
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stages  of  development.  We,  therefore,  take  a  knowledge-based  modeling  approach  to 
evolutionary  prototyping  by  treating  each  evolving  prototype  system  as  a  high-level 
executable  model  of  the  target  system.  The  executable  model  defines  the  structural 
and  behavioral  properties  of  the  target  system  at  any  level  of  abstraction,  as  desired 
by  the  prototyper.  It  evolves  gradually  through  a  series  of  schema  modifications 
and  refinements  to  provide  more  and  more  details  about  the  requirements  and  the 
implementation  of  the  target  system.  At  each  stage  of  evolution,  the  model  of  the 
system  (i.e.,  the  prototype)  can  be  executed  to  test  its  functionalities  and  perfor- 
mance. This  approach  to  evolutionary  prototyping  is  achieved  by  the  use  of  (i)  a 
reflexive  and  extensible  object  model  to  model  the  structural  and  behavioral  proper- 
ties and  constraints  of  data  entities  and  software  components  (including  the  control 
structure  of  methods)  in  a  unified  object-oriented  framework;  (ii)  a  knowledge  base 
management  system  to  manage  persistent  objects,  object  classes  and  their  various 
types  of  associations,  which  model  application  data,  software  systems,  and  their  inter- 
relationships, (iii)  a  powerful  knowledge  base  programming  language  as  the  common 
prototyping  language  to  define,  query,  and  manipulate  the  knowledge  base  as  well 
as  to  code  methods,  and  (iv)  a  KBMS-based  prototyping  environment  to  carry  out 
functionality  tracing  and  performance  evaluation  of  the  evolving  prototypes. 

In  this  dissertation,  we  present  a  KBMS-based  evolutionary  prototyping  method- 
ology for  object-oriented  system  development  and  evaluation.  A  KBMS-based  proto- 
typing language  and  a  KBMS-based  prototyping  environment  are  described.  In  this 
work,  we  have  extended  the  knowledge  base  programming  language  K.3  (which  is  the 


third  version  of  the  K  language  reported  in  [Shy96,  Arr97])  to  support  the  following 
features:  1)  modeling  of  method  implementations  [Su97a],  2)  monitoring  of  inter- 
action among  system  components  using  Event-Condition-Action-Alternative-Action 
(ECAA)  rules,  and  3)  inferring  about  system  behaviors  using  antecedent  consequent 
rules  [Su98].  The  language  is  used  as  a  specification  language  for  modeling  prototypes 
as  well  as  an  implementation  language  for  coding  methods.  K.3  code  is  translated 
into  C++  code  by  a  K.3  compiler,  which  is  then  compiled  into  object  code  by  the 
C-H-  compiler.  We  have  also  developed  a  prototyping  environment  consisting  of  a 
Functionality  Tracing  Monitor  and  a  Performance  Monitor  to  support  the  evaluation 
of  evolving  prototypes  [Su97b].  Our  goal  is  to  reduce  the  gap  between  specification 
and  implementation,  and  to  provide  the  prototyper  with  tools  and  high-level  expres- 
sive language  to  easily  model  and  evaluate  a  target  application  system.  Our  intended 
contribution  is  to  the  field  of  Software  Engineering  by  showing  how  a  semantics- 
rich  object  model,  a  knowledge  base  programming  language,  a  KBMS,  and  the  tools 
and  facilities  of  a  prototyping  environment  can  be  used  to  support  the  evolutionary 
prototyping  process,  thus  reducing  the  cost  and  time  of  developing  object-oriented 
software  systems. 

The  remainder  of  this  dissertation  is  organized  as  follows:  Chapter  2  contains  a 
survey  of  the  related  research  works  pertinent  to  high-level  specification  languages, 
behavioral  modeling  and  knowledge  based  software  environments.  Chapter  3  presents 
the  overall  concept  of  KBMS-based  evolutionary  prototyping  and  discusses  its  domain 
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of  applicability  and  some  of  the  overhead  associated  with  this  methodology.  Chap- 
ter 4  presents  the  knowledge-based  prototyping  language  used  for  modeling  evolving 
prototypes  and  writing  executable  code.  Chapter  5  introduces  the  goals  of  veri- 
fying the  functionality  and  performance  of  prototypes  and  the  role  of  a  KBMS  in 
achieving  these  objectives.  Chapter  6  discusses  the  details  of  a  rule-based  monitoring 
mechanism  for  monitoring  the  interactions  among  software  components.  Chapter  7 
details  the  inferencing  process  to  support  behavior  abstraction  and  behavior  analysis 
of  software  systems.  Chapter  8  discusses  a  prototyping  environment,  and  its  roles 
in  functionality  tracing  and  performance  analysis.  Chapter  9  summarizes  the  main 
contributions  of  this  research  work  and  discusses  some  possible  directions  for  future 
work. 


CHAPTER  2 
SURVEY  OF  RELATED  WORK 


Only  a  few  widely  applicable  and  wide-spectrum  programming  languages  and 
computing  environments,  such  as  GIST  [Par83]  and  V  [Smi85],  are  available  for  sup- 
porting prototyping  efforts.  Most  of  the  existing  prototypes  are  written  either  in  (i) 
some  traditional  implementation  languages,  which  do  not  have  proper  high-level  spec- 
ification facilities  to  capture  the  structural  and  behavioral  properties  of  the  target  sys- 
tem and  are  applicable  only  to  limited  application  domains  due  to  their  lack  of  multi- 
paradigm  constructs,  or  (ii)  some  specification  languages  [Luq88,  Kun89,  Rei87], 
which  are  suitable  for  conceptual  designs  rather  than  for  executable  specifications. 
In  the  former  case  (i),  those  properties,  which  are  not  explicitly  captured  in  the 
domain  specification,  are  buried  in  the  application  code,  thus  reducing  the  system 
readability  and  maintainability.  Besides,  prototypes  become  dependent  on  the  im- 
plementation languages  and,  therefore,  cannot  be  reused  across  different  execution 
environments.  This  problem  introduces  functional  redundancy,  communication  over- 
head, development  and  maintenance  burden,  and  causes  difficulty  in  sharing  data 
and  program  code  among  software  systems.  In  the  latter  case  (ii),  instead  of  evolv- 
ing towards  the  target  system,  prototypes  are  regarded  as  throw-aways  and  have  a 
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short  lifetime  in  the  software  Ufe  cycle.  Since  prototyping  is  separated  from  imple- 
mentation, it  is  difficult  to  debug  and  maintain  an  implemented  system  based  on 
its  requirement  specification  and  design.  For  the  above  reasons,  it  was  suggested 
in  [Bal82]  that  a  common  prototyping  system  (CPS)  is  needed  for  developing  com- 
plex software  systems  in  an  evolutionary  manner.  The  system  should  consist  of  (i) 
a  common  wide-spectrum  prototyping  language  (CPL)  for  both  specifying  and  im- 
plementing a  target  system,  and  (ii)  a  common  prototyping  environment  (CPE)  for 
developing,  executing,  and  testing  the  evolving  prototypes.  We  shall  review  some 
related  work  in  this  chapter. 

The  G-Nets  [Den90],  Petri-Nets  [Rib88],  and  the  Semantic-nets  [Ran88]  were 
proposed  for  prototyping  software  systems,  but  all  of  them  lacked  the  support  of  a 
KBMS,  which,  as  we  shall  show,  is  very  useful  in  the  prototyping  process.  Brodie 
and  Ridjanovic  [Bro83]  proposed  the  ACM/PCM  (Active  and  Passive  Component 
Modeling)  for  the  structural  and  behavioral  modeling  of  a  database  application  using 
an  integrated  object  behavior  schema.  But  there  is  not  enough  information  captured 
in  the  behavior  schema  to  make  it  executable  and  evolvable  into  a  target  system. 
Kappel  and  Schrefl  [Kap91]  proposed  the  use  of  object/behavior  diagrams  as  a  uni- 
form graphic  representation  of  the  object  structure  and  behavior  based  on  a  semantic 
data  model  and  Petri-Nets.  Althoughthis  is  closely  related  to  our  work,  their  proto- 
typing system  is  more  like  a  graphic  tool  and  software  systems  modeled  by  this  type 
of  diagrams  are  not  modeled  uniformly  and  managed  by  an  underlying  KBMS.  Our 
prototyping  language  K.3  is  similar  to  model-based  specification  languages  such  as 
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VDM  [Bjo82]  and  Z  [AbrSO]  in  that  they  are  also  used  to  formulate  models  of  software 
systems.  But  VDM  and  Z  are  strictly  specification  languages  without  any  persistent 
knowledge  base  support.  Our  language  K.3  is  similar  to  Eiffel  [Mey92],  an  object- 
oriented  programming  language,  in  many  respects.  However,  Eiffel  does  not  provide 
persistent  support  to  application  objects  and  does  not  have  a  KBMS  support  for  mod- 
eling constructs  equivalent  to  our  control  associations.  Carolyne  Pe  Rosiene  and  Reda 
A.  Ammar  [Ros93]  proposed  a  data  modeling  approach  for  carrying  out  performance 
evaluation;  however,  it  lacks  a  refinement  operator  such  as  Decomposition,  which  is 
provided  in  our  prototyping  language  for  gradually  decomposing  a  prototype  system 
into  lower  levels  of  details.  Moreover,  their  language  lacks  active  rules  and  a  KBMS 
support  for  carrying  out  various  activities  of  software  development.  The  commercial 
product  Rational  Rose  combines  Booch,  Rumbaugh,  and  Jacobson's  object-oriented 
design  and  analysis  methodologies.  Rational  Rose  supports  the  Unified  Modeling 
Language  (UML)  specification  [Uml98]  of  a  system  through  use/case  diagrams,  class 
diagrams,  behavior  diagrams,  and  implementation  diagrams.  It  generates  class  and 
method  skeletons  of  the  target  system  from  user-specified  diagrams.  The  methods 
are  then  coded  by  developers  to  implement  the  desired  semantics.  Rational  Rose  is 
a  system  for  supporting  system  design  and  analysis  instead  of  an  executable  proto- 
typing tool.  It  also  lacks  rule  specification  and  processing  facilities,  which  are  used 
for  modeling  and  enforcing  constraints  among  different  system  components  and  data 
entities. 
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KEE  (Knowledge  Engineering  Environment)  [Fik85,  Fil88,  Twi89]  system  which 
integrates  the  concepts  of  production  rules,  frames,  and  object-oriented  programming, 
has  been  used  as  a  knowledge-base  system  development  environment.  However,  it 
lacks  the  support  of  active  rule  specification  in  their  frames  specification,  which  is 
very  useful  for  specifying  constraints  at  various  levels  of  abstraction,  as  we  shall  see 
later  on  in  this  dissertation.  Our  prototyping  system  supports  the  specification  of 
both  active  and  deductive  rules.  Performance  monitoring  of  the  target  system  is  not 
supported  by  the  KEE  system  but  is  supported  by  our  knowledge-based  prototyping 
environment.  The  procedures  attached  to  the  frames  in  KEE  are  in  lisp  which  is 
an  interpretive  language.  Whereas  our  K.3  implementation  code  is  translated  into 
C-l— I-  code,  which  is  compiled  into  object  code.  The  compiled  code  is  much  faster  at 
run-time.  Moreover  our  prototyping  system  supports  a  wider  variety  of  constraints 
than  those  supported  by  the  KEE  system.  ART  (Automated  Reasoning  Tool)  [Art88] 
is  an  expert  system  written  in  lisp  which  supports  facilities  like  objects,  production 
rules,  truth  maintenance,  and  object-oriented  programming.  ART  and  it's  deriva- 
tives ART-IM  (Automated  Reasoning  Tool  for  Information  Management,  written  in 
C)  [Art89],  and  ART- Ada  (an  expert  system  which  was  built  based  on  the  architec- 
ture of  ART  and  ART-IM  and  was  written  in  Ada)  [Lee90]  have  been  used  to  provide 
the  environments  for  developing  knowledge-based  applications.  However,  they  lack 
the  active  rule  specification  and  processing  capabilities.  Our  prototyping  system 
supports  both  the  state-based  production  rules  and  the  event-based  active  rules  and 
thus  has  an  advantage  over  these  systems.  Moreover,  ART  and  its  derivative  systems 
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do  not  provide  performance  monitoring  and  analysis  facilities  for  evaluating  appli- 
cations systems  that  are  being  developed,  nor  do  they  support  the  specification  and 
processing  of  constraints  which  is  a  part  of  the  declarative  specification  mechanism 
in  our  system.  ART  supports  both  schema  (which  have  all  the  object  property,  like 
inheritance,  attributes,  etc.)  as  well  as  lisp  lists  (which  are  a  set  of  typeless  fields). 
Whereas,  our  system  is  strongly  typed  and  all  the  objects  are  either  entity  class  ob- 
jects or  domain  class  objects.  This  strongly  typed  property  helps  to  make  the  target 
specification  less  error  prone  because  the  type  mismatch  error  can  be  detected  by  the 
compiler  at  compilation  time. 

In  our  work,  we  extend  an  object  model  and  a  knowledge  base  programming 
language  to  model  data  entities,  software  components  and  complex  methods  and  to 
write  simulated  or  real  code  for  simple  methods  that  the  prototyper  can  write.  The 
modeling  of  complex  methods  and  the  generation  of  executable  code  from  method 
models  are  not  supported  by  existing  prototyping  systems.  We  also  introduce  rule- 
based  specifications  of  constraints  among  system  components,  to  enhance  the  ex- 
pressive power  of  our  model  and  language.  Unlike  any  existing  prototyping  system, 
our  system  supports  both  Event-Condition-Action-Alternative- Action  (ECAA)  rules 
and  state-based  inferencing  rules.  The  ECAA  rules  are  used  for  implementing  sys- 
tem constraints  at  different  levels  of  abstraction.  For  example,  they  can  be  used 
to  implement  inter-component,  inter-method,  and  intra-method  constraints.  They 
are  also  used  for  monitoring  the  interactions  among  different  components  of  a  pro- 
totype system  at  run-time.  The  state  rules  are  used  for  deducing  useful  information 


12 


from  monitored  data  for  the  behavior  abstraction  and  analysis  of  a  prototype  system. 
Our  prototyping  language  is  supported  by  a  KBMS-based  prototyping  environment 
which  consists  of  a  Functionality  Tracing  Monitor  and  a  Performance  Monitor  for 
tracing  program  execution  and  recording  the  time  taken  to  execute  different  parts  of 
a  prototype. 


CHAPTER  3 
KBMS-BASED  EVOLUTIONARY  PROTOTYPING  METHODOLOGY 


The  KBMS-based  evolutionary  prototyping  process  is  shown  in  Figure  3.1. 
Based  on  the  initial  knowledge  of  the  prototyper  about  the  system  requirements, 
the  prototyper  uses  the  common  prototyping  language  K.3  to  model  the  components 
and  complex  methods  of  the  initial  prototype.  The  language  is  also  used  to  write 
code  for  simple  methods.  Its  language  constructs  will  be  discussed  in  Chapter  4. 
The  specifications  are  then  executed  in  the  prototyping  environment.  The  Perfor- 
mance Monitor  and  the  Functionality  Tracing  Monitor  which  will  be  discussed  in 
Chapter  8,  are  used  for  performance  evaluation  and  for  tracing  the  execution  of  the 
system.  If  the  results  of  evaluation  are  not  satisfactory,  then  the  prototyper  can  go 
back  to  change  the  model  and  repeat  the  process  of  execution  and  analysis.  The 
conceptual  model  of  the  prototype  system  is  gradually  modified  and  extended  (i.e., 
schema  evolution).  The  conceptual  model  derived  at  any  stage  is  executable  since  the 
methods  associated  with  the  object  classes  that  model  the  system  components  are 
either  implemented  by  real  or  simulated  codes  in  K.3  or  explicitly  modeled  as  a  con- 
trol structure  of  code  blocks  which  is  translated  into  executable  code  by  a  Program 
Generator.  The  Program  Generator  will  be  discussed  in  Chapter  4.  Since  the  struc- 
tural and  functional  relationships  among  system  components  are  explicitly  specified 
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in  the  conceptual  model  of  the  system  being  developed  and  are  stored  in  a  knowledge 
base,  they  can  be  queried  and  accessed  by  the  prototyper  as  knowledge  base  accesses. 
Through  an  iterative  process  of  modeling  the  system,  executing  the  model  for  testing 
its  functionality  and  performance,  inquiring  the  structural  and  functional  relation- 
ships of  the  system  components,  and  modifying  the  model  as  more  knowledge  about 
the  system  has  been  gained,  a  series  of  prototypes  will  be  generated  and  tested  until 
the  final  target  system  (the  last  evaluated  prototype)  is  derived  and  released  for  use. 

Throughout  this  software  development  process,  a  KBMS  as  well  as  a  knowledge 
base  programming  language,  which  serves  as  the  high-level  interface  to  the  KBMS, 
are  used  to  provide  the  following  facilities:  (i)  a  persistent  storage  and  schema  evo- 
lution mechanism  for  recording  the  changes  to  the  prototype  system,  the  execution 
results  of  the  prototype  system  at  every  stage  of  prototyping,  and  other  meta-data 
such  as  designers'  information,  requirements,  schedules,  milestone  reports,  design  de- 
cisions, comments,  and  expert  knowledge  rules,  (ii)  querying  and  object  management' 
facilities  for  accessing  the  KBMS,  (iii)  a  rule  processing  mechanism  for  supporting 
consistency  checking,  integrity  enforcement,  deduction,  and  automatic  triggering  of 
Event-Condicion-Action-Alternative-Action  (ECAA)  rules. 

The  knowledge  base  programming  language  called  K.3  uses  an  object-oriented 
semantic  association  model  called  OSAM*  [Su83,  Su89a,  Su89bJ  as  its  underlying 
object  model.  It  has  an  extensible  kernel  called  XKOM  [Yas91],  and  is  used  during 
the  prototyping  process.  In  this  language,  object  classes  are  used  as  the  knowledge 
definition  facility  to  provide  knowledge  encapsulation  by  allowing  an  object  class  to 
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be  defined  in  terms  of  its  structural  and  functional  associations  with  other  classes, 
operations,  and  rules  in  an  integrated  fashion.  Rules  in  K.3  are  Event-Condition- 
Action-Alternative-Action  (ECAA)  rules,  vifhich  can  be  used  to  model  all  sorts  of 
system  and  data  constraints,  and  deductive  rules,  which  can  be  used  for  inferring 
system  behavior  at  run-time,  and  for  supporting  its  behavior  analysis.  These  two 
types  of  rules  will  be  discussed  in  details  in  Chapters  6  and  7,  respectively.  There  are 
two  types  of  classes:  domain  classes,  which  define  domains  of  the  possible  values  from 
which  descriptive  attributes  of  objects  draw  their  values,  and  entity  classes,  which 
define  and  contain  objects  found  in  an  application's  world,  such  as  physical  entities, 
abstract  things,  events,  processes,  and  relationships.  The  encapsulation  and  inheri- 
tance features  are  also  built  into  OSAM*  classes.  The  OSAM*  class  system  has  been 
extended  to  achieve  model  extensibility  by  uniformly  modeling  application  systems 
in  any  application  domain  (including  the  model  itself)  as  classes.  Parametrized  rules 
are  used  to  define  new  class  types,  association  types  and  constraint  types.  Structural 
associations,  methods,  and  rules  are  all  first  class  objects.  Thus,  the  structural  and 
the  behavioral  properties  of  entities  are  uniformly  captured  and  represented  in  the 
knowledge  model  as  objects. 

One  of  the  main  features  of  K.3  is  the  support  for  persistence  which  is  an 
instance  property  rather  than  a  class  property.  Persistence  is  independent  of  the 
physical  address  of  the  object  instances  and  is  orthogonal  to  queries  and  object  ma- 
nipulations. Moreover,  a  declarative  and  set-oriented  high-level  query  language  has 
been  seamlessly  incorporated  into  the  language  constructs  of  K.3  for  retrieving  and 
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manipulating  persistent  and  transient  objects.  K.3  also  provides  a  multi-paradigm 
computational  facility.  As  a  computationally  complete  programming  language,  K.3 
provides  all  the  basic  control  structures  such  as  sequential,  iteration,  and  branching 
statements.  Parallel,  distributed,  non-deterministic  and  real-time  computational  fa- 
cilities can  be  built  into  the  extensible  object  model  as  extensions  of  K.3.  Besides 
all  the  procedural  constructs,  we  have  also  provided  a  mechanism  for  modeling  a 
complex  method  implementation  by  a  structure  of  code  blocks  which  are  defined  as 
K.3  classes  and  are  linked  with  one  another  by  a  number  of  control  associations: 
namely.  Decomposition,  Sequential,  Testing,  Case,  Parallel,  Synchronization,  ForE- 
ach,  and  Loop.  Each  code  block  contains  a  piece  of  code  that  a  prototyper  can 
comfortably  and  correctly  write.  The  structure  of  code  blocks  is  used  to  generate 
the  executable  code  for  the  complex  method.  The  underlying  extensible  OSAM* 
model  enables  the  prototyper  to  model  data  entities,  program  modules,  and  method 
models  uniformly  in  terms  of  object  classes  and  their  various  types  of  associations. 
By  using  a  single  unified  knowledge  model  and  schema  notation,  we  eliminate  the 
mismatch  between  the  traditional  data-oriented  models  [Hul87]  and  process-oriented 
models  [Nas73,  PetSlj  to  support  both  structural  and  behavioral  prototyping  within 
an  object-oriented  framework. 

A  KBMS  is  used  for  supporting  evolutionary  prototyping  process.  It  consists  of 
a  query  processor  for  processing  queries,  a  rule  processor  for  processing  rules  defined 
in  the  different  classes,  a  data  dictionary  handler  for  managing  the  meta-data  stored 
in  the  KB,  and  an  object  manager,  which  is  built  on  top  of  EXODUS,  for  providing 
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supports  for  object  persistence  and  basic  object  maintenance  and  manipulation. 
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Figure  3.1.  An  Overview  of  the  Evolutionary  Prototyping  Process 


The  KBMS-based  evolutionary  prototyping  methodology  can  be  used  for  devel- 
oping any  object-oriented  software  system  in  such  application  domains  as  decision 
support,  manufacturing  automation  and  business  data  processing.  There  are  several 
advantages  in  using  this  methodology.  First,  the  prototyping  language  is  semanti- 
cally  rich.  It  provides  constructs  for  both  the  specification  and  implementation  of 
an  evolving  prototype  system.  Second,  the  KBMS  provides  persistence,  query,  and 
rule  processing  supports  for  prototyping.  Third,  the  prototyping  environment  sup- 
ports the  tracing  and  performance  evaluation  of  prototypes.  Our  methodology  also 
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addresses  the  maintenance  issue  which  is  one  of  the  major  problems  with  the  evolu- 
tionary prototyping  process.  Continual  change  in  the  prototype  tends  to  corrupt  the 
software  structure  and  therefore  makes  the  system  maintenance  difficult  and  costly. 
We  present  a  semantically  rich  object-oriented  modeling  language  with  constraints 
and  ECAA  rules  as  a  part  of  object  specification,  which  reduces  the  unstructuredness 
in  the  code  brought  about  by  continual  change,  increases  cohesion  of  a  component, 
reduces  coupling  between  components,  makes  the  system  more  adaptable,  and  makes 
the  code  more  easy  to  read  and  understand,  thereby  keeping  the  maintenance  cost 
low.  We  address  the  issue  of  reducing  the  chances  of  adding  unstructuredness  in 
the  code  during  the  changes  made  during  the  maintenance  phase  by  the  following 
mechanisms.  First,  our  programming  language  supports  all  the  control  statements 
(if-then-else,  while-do,  do-while  etc.)  of  any  structured  programming  language,  and 
avoids  the  usage  of  go-to  statement  which  is  an  unconditional  jump  statement,  which 
tends  to  disrupt  the  structure  of  a  program.  Secondly,  we  present  modeling  con- 
structs to  represent  knowledge  about  system  constraints  and  behaviors,  in  terms  of 
high-level  declarative  constructs  like  ECAA  rules  and  constraints  which  are  much 
easier  to  specify  and  change,  rather  than  procedural  code.  The  procedural  code  to 
implement  the  semantics  of  these  rules  and  constraints  is  automatically  generated, 
thus  reducing  the  chances  of  making  mistakes  or  corrupting  design  integrity.  Thirdly, 
we  support  modeling  constructs  in  the  language  for  specifying  structural,  behavioral, 
and  knowledge  abstractions,  to  represent  all  the  structural  and  behavioral  properties, 
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and  constraints  of  an  object,  as  a  part  of  object's  specification  rather  than  embed- 
ding them  through  out  the  system  code  where  the  object's  services  are  being  used. 
Thus  when  the  rules  and  constraints  of  the  system  changes  we  only  need  to  change 
the  object's  specification,  rather  than  changing  all  those  places  in  the  code  where 
the  object's  services  are  being  used.  Thus,  this  mechanism  also  supports  controlled 
change  during  the  evolution  of  a  prototype.  We  will  discuss  the  language  features 
and  constructs  in  details  in  Chapter  4.  However,  there  is  a  learning  curve  involved 
in  our  methodology.  The  prototyper  needs  to  be  knowledgeable  about  the  various 
language/environment  capabilities  provided  by  the  system  to  make  the  best  use  of 
it. 

To  summarize  the  concept  of  KBMS-based  evolutionary  prototyping,  we  stress 
that  the  next  generation  prototyping  system  should  treat  a  prototype  as  a  high- 
level  executable  model  of  the  target  system  for  gathering  structural,  behavioral,  and 
performance  information  about  the  system.  The  model  can  gradually  evolve  into  the 
final  system  as  more  and  more  details  are  specified  in  the  model.  To  achieve  this, 
the  following  components  are  needed:  i)  a  KBMS,  which  is  based  on  an  expressive 
and  extensible  knowledge  model,  which  can  model  software  systems  to  be  developed 
for  a  wide  range  of  application  domains,  ii)  a  wide-spectrum  and  computationally 
complete  prototyping  language  capable  of  defining  and  implementing  any  part  of 
a  prototype  system  to  any  level  of  detail.  It  should  be  reflexive  of  the  knowledge 
model  so  that  modification  or  extension  to  the  knowledge  model  will  automatically 
modify  and  extend  the  prototyping  language  to  cope  with  changing  environments 


and  requirements.  It  should  provide  constructs  for  specifying  sequential,  parallel, 
non-deterministic,  real-time,  distributed,  and  rule-based  processing  to  capture  the 
various  behavioral  aspects  of  different  application  domains.  Lastly,  on  top  of  the 
KBMS  and  the  prototyping  language,  a  common  prototyping  environment  is  needed 
to  support  all  the  activities  in  an  evolutionary  software  development  life  cycle. 
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CHAPTER  4 
KNOWLEDGE-BASED  PROTOTYPING  LANGUAGE 


4.1     Object  Model 

The  underlying  data  model  of  our  prototyping  language  K.3  is  based  on  the 
object-oriented  semantic  association  model  called  OSAM*.  In  this  model,  all  things 
of  interest  in  an  application  are  modeled  by  means  of  object  classes.  An  object  class  is 
defined  in  terms  of  its  structural  properties,  operational  characteristics,  and  knowl- 
edge rules.  The  relationships  amongst  classes  are  modeled  by  means  of  semantic 
associations.  The  operational  properties  are  defined  by  means  of  methods.  Con- 
straints, and  expert  knowledge  related  to  a  class  are  specified  by  means  of  knowledge 
rules.  The  model  of  the  model,  i.e.,  the  meta-model,  is  modeled  by  using  the  con- 
structs provided  by  the  language.  Since  our  underlying  data  model  is  object-oriented, 
and  the  implementation  language  K.3  is  also  object-oriented,  they  both  possess  the 
advantages  of  any  object-oriented  model/language;  namely,  information  hiding,  en- 
capsulation, inheritance,  polymorphism,  etc.  Also  different  objects  interact  with  one 
another  via  message  passing  instead  of  operating  directly  on  each  other's  data.  They 
are  loosely  coupled  with  one  another.  This  reduces  coupling  between  different  mod- 
ules. Moreover,  the  support  for  inheritance  feature  in  our  language  makes  components 
readily  adaptable.  The  adaptation  relies  on  creating  a  new  component  which  inherits 
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the  attributes  and  operations  of  the  original  component.  Only  those  attributes  and 
operations  which  need  to  be  changed  are  modified.  Components,  which  rely  on  the 
base  component,  are  not  affected  by  the  changes  made.  These  features  reduce  the 
maintenance  cost  of  the  system.  We  now  present  different  modeling  constructs  in 
OSAM*. 

Schema:  A  schema,  in  this  work,  is  a  specification  of  the  components  of  a 
software  system  being  developed  and  the  data  entities  these  components  use  and 
manipulate.  It  consists  of  domain  classes,  entity  classes,  and  deductive  rules.  These 
constructs  and  their  properties  are  discussed  below. 

Objects:  Objects  are  representations  of  things  that  occur  in  an  application's 
world,  including  physical  entities,  processes,  abstract  things,  relationships  and  values. 
Objects  are  interconnected  by  means  of  semantic  associations,  which  specify  the 
semantics  of  their  relationships.  At  the  extensional  level  an  object-oriented  database 
is  represented  as  a  network  of  interconnected  objects. 

Classes:  Classes  are  abstractions  used  to  define  and  group  objects  that  have 
common  properties.  A  class  is  used  to  define  the  common  properties  of  a  group  of 
objects  in  terms  of  their  structural  and  operational  semantics  (behavior) .  These  prop- 
erties are  described  by  means  of  semantic  associations,  methods  and  ECAA  rules,  as 
shall  be  described  below.  The  data  representation  of  an  object  in  a  class  is  called  the 
"instance"  of  the  object  in  that  class.  The  "type"  of  a  class  describes  the  properties 
that  are  common  to  all  the  instances  of  the  class.  Two  general  types  of  classes  are 
defined  in  the  basic  (kernel)  object  model:  entity  class  and  domain  class.  An  entity 
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class  defines  and  groups  objects  of  interest  in  an  application.  Entity  objects  have  their 
independent  identities  and  are  uniquely  identified  by  their  object  identifiers  (oids). 
Entity  classes  may  have  associations  with  other  Entity  classes  and  Domain  classes, 
which  represent  their  structural  properties.  Their  behavioral  properties  are  defined  in 
terms  of  methods.  They  may  also  have  Event-Condition-Action-Alternative-Action 
(ECAA)  rules,  which  specify  knowledge  rules  and  constraints.  Domain  class  defines 
objects  that  do  not  exist  independently  in  the  database  bat  are  used  to  specify  the 
descriptive  properties  (attribute  values)  and/or  associate  properties  (object  associa- 
tions) of  entity  objects.  Domain  objects  are  self-naming.  For  example,  the  integer 
10  and  name  "John  Smith"  can  be  domain  objects. 

Associations:  Semantic  associations  represent  relationships  among  object  classes 
and  their  instances.  An  association  is  defined  by  a  set  of  links  each  of  which  is  di- 
rected from  the  class  where  it  is  defined  called  the  "defining  class"  to  each  of  the 
"constituent  classes."  The  "type"  of  an  association  describes  the  semantics  of  the 
relationship  it  represents.  Two  types  of  associations  are  part  of  the  kernel  object 
model:  generalization  and  aggregation.  A  generalization  association  is  used  to  model 
the  relationship  that  a  constituent  class  is  a  subclass  of  the  defining  class  (the  su- 
perclass), and  the  subclass  inherits  all  the  properties  (associations,  methods,  rules) 
of  the  superclass.  An  aggregation  association  models  the  relationship  that  an  object 
of  the  constituent  class  as  the  value  of  a  data  attribute  (or  "data  member")  of  the 
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defining  class.  Notice  that  these  two  association  types  are  common  in  most  object- 
oriented  data  models.  Other  association  types  are  defined  using  a  model  extensibility 
mechanism  [Arr97]. 

Methods;  Methods  are  used  to  implement  some  procedural  semantics  of  objects. 
A  method  consists  of  a  "signature"  (or  specification),  which  includes  the  method 
name,  the  names  and  types  of  its  parameters  and  an  optional  return  type,  and  a 
"body"  which  is  the  implementation  of  the  method.  A  method,  when  executed, 
changes  the  "state"  of  an  object  and/or  other  objects.  A  method  is  executed  by 
sending  a  message  to  the  desired  object.  The  message  contains  the  method  signature 
and  the  parameter  values. 

Rules:  Two  types  of  rules  are  supported  in  OSAM*:  ECAA  rules  and  deductive 
rules.  ECAA  rules  are  event-based  procedural  rules  whereas  the  deductive  rules  are 
state-based  inferencing  rules.  ECAA  rules  are  used  to  represent  operational  semantics 
of  objects  at  the  specification  level  instead  of  the  implementation  level.  An  ECAA 
rule  is  an  abstraction  which  represents  a  set  of  actions  to  be  performed  when  certain 
events  occur  (i.e.  the  rule  is  "triggered").  An  event  can  be  a  system-defined  operation 
such  as  create,  update,  delete,  insert  or  a  user-defined  operation  specified  as  a  method. 
The  "activation  policy"  or  "coupling  mode"  of  an  ECAA  rule  indicates  when  the  rule 
is  to  be  triggered  with  respect  to  an  event,  i.e.  before  the  event,  after  the  event, 
etc.  The  "event"  specification  of  the  rule  indicates  which  events  cause  the  rule  to  be 
triggered.  The  "condition"  specification  in  a  rule  is  a  guarded  expression  which  is 
evaluated  upon  the  triggering  of  the  rule  and  used  to  determine  whether  to  perform 
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the  rule's  "action"  (if  the  condition  is  TRUE)  or  the  rule's  "alternative  action"  (if 
the  condition  is  FALSE)  or  to  skip  the  action  and  the  alternative  action  (if  any  guard 
is  FALSE).  The  action  and  alternative  action  parts  of  the  rule  specify  the  predefined 
operations  associated  with  objects.  The  ECAA  rule  specification  is  used  to  specify 
the  constraints  and  behaviors  of  an  object  as  a  part  of  the  object  specification,  so 
they  need  not  be  enforced  by  the  clients  which  use  that  object.  In  other  words, 
the  knowledge  about  the  behaviors  and  constraints  of  the  object  is  represented  in  a 
structured  manner  in  terms  of  ECAA  rules  as  a  part  of  the  object  specification,  rather 
than  being  dispersed  throughout  the  system  in  the  places  where  the  object's  services 
are  being  used.  Thus,  the  specification  for  checking  of  constraints  is  done  only  once  at 
one  place.  If  any  constraint  changes  at  a  later  point  in  time,  it  needs  to  be  modified 
at  only  one  place,  and  all  the  client  classes  of  that  object  will  automatically  see  the 
effect  of  the  change,  without  having  to  change  all  the  client  code  that  made  use 
of  the  object.  This  reduces  the  possibility  of  adding  unstructured  code  in  multiple 
places,  thus  simplifying  the  system  maintenance  task.  This  also  reduces  the  coupling 
between  different  objects,  increases  cohesion  of  a  particular  object,  and  thus  results 
in  a  well-structured  specification  of  the  system  because  all  the  knowledge  about  its 
structures,  behaviors  and  constraints  are  specified  within  its  own  specification,  rather 
than  being  scattered  throughout  the  system.  All  the  above  properties  make  the  code 
easier  to  maintain.  ECAA  rules  are  high-level  specifications  of  system  behaviors, 
which  are  translated  into  program  code. 
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In  addition  to  ECAA  rules,  it  is  useful  to  have  another  rule  specification  mech- 
anism to  allow  the  prototyper  to  state  the  implication  of  some  observed  behaviors 
of  a  system  (e.g.,  a  deadlock  is  implied  by  a  cyclic  wait-for  condition).  Since  the 
implied  fact(s)  is  not  generated  by  the  execution  of  the  prototype  and  thus  cannot 
be  generated  by  ECAA  rules,  a  state-based  deductive  rule  specification  mechanism 
is  also  used  in  this  work.  The  deductive  rules  have  two  major  components,  namely 
antecedent  and  consequent.  The  antecedent  is  made  up  of  a  list  of  clauses  which, 
if  evaluated  to  true,  will  imply  that  the  statements  in  the  consequent  are  also  true. 
Both  types  of  rules  will  be  discussed  in  details  in  later  chapters. 

4.2     Modeling  Prototvpe 

A  software  system  or  its  prototype  is  made  up  of  data  entities  and  software 
components,  which  manage  and  manipulate  the  data  entities.  Using  the  prototyping 
language  K.3,  data  entities  and  software  components  are  uniformly  modeled  by  object 
classes  with  attributes,  methods  and  knowledge  rules.  Method  implementations  or 
simulation  code  for  methods  are  also  written  in  K.3.  Thus,  the  prototyping  language 
K.3  is  both  a  specification  language  as  well  as  an  implementation  language.  The 
following  example  shows  the  use  of  K.3  to  model  a  data  entity  type  called  Product. 


define  Product    :   Entity   in  ManufSchema  is 

associations: 

public : 

Aggregation  -> 

{ 

product_code  :  Integer  where  UNIQUE (product_code) ; 

description  :  Text; 

components  :  Set<Component>; 
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design  :  ProductDesign; 


methods : 

method  displayO ; 

method  add_comp(c_no  :  String,  p:Part); 

where{method_model  :=  "ProductAddCompSchema"}; 
method  product_cost() ; 

rules : 

rule  should_have_board  is 

triggered  after  createO,   update  (components) 
//  create 0   and  update ()   system  defined  methods 
condition 

exist  b  in  this  *    [components]   Component 
*  p:Part   *  b: Board 
//  the  above   condition  checks  whether  the  newly 
//  created  or  updated 
//  Product   (identified  by   ''this'') 
//  is  associated  with  a  board  via  some  objects 
//  of  Component  and  Part 
otherwise 

"RULE:    Product : : should_have_board\n" .displayO ; 
"*ERROR*  Component   should  have   a  board    !\n" .displayO ; 
delO;     //  if  condition  is  not  satisfied  then  delete 
//  this  Product  instance 
end; 
end  Product; 


In  the  above  example,  the  structural  properties  of  Product  is  specified  in  the 
section  labeled  associations.  It  consists  of  product_code,  description  of  the  product, 
information  about  the  set  of  components  of  the  product,  and  some  information  about 
the  design  of  the  product.  The  UNIQUE  constraint  of  the  product.code  attribute 
specifies  that  the  product  code  must  be  unique  for  each  instance  of  the  product 
type.  There  are  many  other  types  of  constraints  supported  by  our  system.  They 
are  Range,  Set  Exclusion  (SetExcl),  Set  Equality  (SetEq),  Set  Subset  (SetSub),  Key, 
Fixed,  maximum  number  of  instances  of  an  entity  (MaxObjects),  Total  Participation 
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(Total),  Cardinality  among  Interaction  members  (ICard),  Cardinality  among  defin- 
ing class  and  a  constituent  class  (ACard),  Total  Specialization  (TS),  Composite  Key, 
Derive,  Inverse,  Enumeration  (Enum),  and  Partial  Participation  with  count.  These 
constraints  can  be  used  to  explicitly  and  declaratively  specify  the  constraints  associ- 
ated with  data  and  software  components.  Without  them,  the  constraints  will  have  to 
be  implemented  and  thus  buried  in  procedural  code.  When  the  constraints  are  to  be 
modified,  we  can  make  changes  in  a  declarative  manner  instead  of  making  changes  to 
the  procedural  code.  Since  the  procedural  code  that  implement  the  semantics  of  these 
constraints  can  be  automatically  generated  from  the  specifications,  it  avoids  the  mis- 
takes that  are  frequently  made  in  making  changes  to  written  code.  Also,  high-level 
specifications  are  easier  to  read  and  understand  than  procedural  code,  thus  reducing 
the  system  maintenance  overhead.  The  methods  provide  an  interface  for  performing 
operations  on  different  structural  parts  of  the  class,  e.g.,  the  method  add-Comp()  is 
used  to  add  a  component  of  the  product.  In  the  above  example,  a  rule  is  used  to 
specify  a  data  integrity  constraint.  It  is  triggered  after  creating  or  updating  a  product 
to  check  whether  one  of  the  component  parts  of  the  product  has  a  board.  If  not,  an 
error  condition  is  raised,  and  the  Product  instance  is  deleted  from  the  KB. 

Similar  to  data  entities,  software  system  components  can  also  be  modeled  using 
K.3.  The  following  definitions  of  MainMaint  and  ProductMaint  illustrate  this: 


define  MainMaint    :   Entity  in  ManufProgSchema   is 

associations ; 

public: 

Aggregation  -> 

{ 
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pmaint  :  PartMaint ; 
prmaint  :  ProductMaint; 
ctmaint  :  CircuitMaint; 
menu. choice  :  Integer; 


methods: 

public: 

method  mainO  ; 

method  display _menu() ; 

method  get_choice() ; 

method  branch () ; 

end  MainMaint ; 


define  ProductMaint : Entity  in  ManufProgSchema  is 

associations: 

public : 

Aggregation  -> 

{ 

product  ;  Product; 
}; 

private: 
Aggregation  -> 
{ 

menu_choice  :  Integer; 

part  :  Part ; 

>; 

methods : 

public : 

method  display _menu() ; 

method  get_choice() ; 

method  branch () ; 

method  add_product() ; 

method  modif y_product (product.code : Integer ,part_no : Integer) ; 

method  general_register_algo() ; 

method  minimum_register_algo() ; 

method  del_product() ; 

method  get_product() ; 

method  add_comp()  where  {method.model  :=  "AddCompSchema" ;} 

method  mainO ; 

rules: 
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//  Note  the  registering  is  required  after  an  update  is  performed 
rule  choose_register_algo   is 

triggered  after  modify_product(product_code : Integer , 

part_no : Integer) 
condition 

exist  p  in  p; Product  *   [components]   Component 

*  pt : Part  where 
p   !=  this  and  p.product.code  <  product_code 
and  pt . part_no  <  part_no 
action 

general_register_aIgo() ; 
otherwise 

minimum_register_algo() ; 
end; 
end  ProductMaint : 


The  structural,  behavior,  and  knowledge  abstractions  shown  in  the  above  ex- 
amples are  explained  below; 

Structural  Abstraction:  The  MainMaint  is  the  software  component  which 
maintains  all  the  data  entities  of  the  system.  The  association  section  of  the  Main- 
Maint class  contains  the  aggregation  of  pmaint,  prmaint,  ctmaint,  and  menu_choice. 
The  menu_choice  is  a  data  attribute  of  the  MainMaint  class,  whereas  the  other  three 
are  the  software  components  which  are  used  to  model  software  components  for  main- 
taining the  part,  product,  and  circuit  data  entities,  respectively.  Due  to  lack  of  space, 
we  have  only  shown  the  ProductMaint  class,  which  is  the  component  for  maintain- 
ing the  Product  data  entity.  The  ProductMaint  class  has  the  public  data  attribute 
product,  and  the  private  data  attributes  menuxhoice  and  part. 

Behavior  Abstraction:  The  behavior  abstraction  is  specified  in  terms  of  meth- 
ods in  a  class.  Each  method  definition  consists  of  two  parts:  (i)  a  signature,  which 
is  given  in  the  methods  section  of  a  class  definition  and  specifies  the  name  of  the 
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method,  the  types  of  the  parameters,  and  the  type  of  the  return  value,  and  (ii)  the 
actual  method  body,  which  is  given  in  the  implementation  section  of  a  class  defini- 
tion and  is  a  sequence  of  K.3  statements  that  contain  local  variable  declarations  and 
do  general  computations.  The  signature  part  provides  the  behavior  abstraction.  It 
contains  the  information  as  to  whether  the  method  is  public  or  private,  the  name  of 
the  method,  and  the  names  and  the  types  of  the  different  parameters.  The  class  Pro- 
ductMaint  has  a  method  "modify .product"  whose  specification  is  as  follows:  "public: 
method  modify _product(product_code:Integer,  partJio:Integer)."  This  method  spec- 
ification provides  a  high-level  abstraction  of  the  process  of  modifying  a  product  by 
hiding  the  details  of  the  actual  modification. 

Knowledge  Abstraction:  ECAA  rules  serve  as  a  high-level  mechanism  for 
specifying  declarative  knowledge  that  governs  the  manipulations  of  objects  made  by 
the  KBMS.  Each  rule  is  given  a  name  for  its  identification,  which  must  be  unique 
within  its  defining  class.  Each  rule  is  specified  by  a  set  of  trigger  conditions  and  a 
rule  body.  Each  trigger  condition  consists  of  a  timing  specification  and  a  sequence 
of  knowledge-base  event  specification.  The  timing  specification  (or  coupling  mode) 
can  be  "before,"  "after,"  or  "on_commit."  The  event  specification  can  be  a  KBMS 
operation,  an  update,  or  any  user-defined  method.  The  rule  body  consists  of  (i)  a 
"condition"  clause  which  is  a  predicate  expression  which  evaluates  to  True  or  False 
or  a  guarded  expression  that  evaluates  to  True,  False  or  Skip  (i.e.,  neither  the  action- 
clause  nor  the  otherwise-clause  part  of  the  rule  is  executed),  and  (ii)  "action"  and 
"otherwise"  clauses,  both  of  which  can  be  a  sequence  of  K.3  computation  statements. 
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Similar  to  method  invocation,  rule  checking  is  performed  at  the  instance  level,  and 
the  pseudo  variable  "this"  can  be  used  in  a  rule  body  to  refer  to  the  current  instance 
of  the  defining  class  on  which  some  operation  (event)  is  performed. 

The  rule  body  of  each  rule  is  evaluated  as  follows:  (i)  if  the  condition-clause 
returns  true,  then  the  action-clause  (if  provided)  is  executed,  (ii)  if  the  condition- 
clause  returns  skip  (see  a  guarded  expression  below),  then  do-nothing,  and  (iii)  if  the 
condition-clause  returns  false,  then  the  otherwise-clause  (if  provided)  is  executed.  For 
example  the  choose  j-egister_algo  rule  in  the  ProductMaint  class  is  used  to  specify  the 
property  that  if  the  product  code  number  and  the  part  code  number  of  a  product 
is  minimum  amongst  all  the  products,  then  the  minimumj-egister_algo()  should  be 
invoked  immediately  after  modifying  a  product,  or  else  the  generalj-egister^lgo() 
should  be  invoked.  The  condition  part  of  this  rule  consists  of  an  association  pattern 
specification  (i.e.,  a  query  for  identifying  all  Products  and  their  Components  and 
Parts).  Based  on  its  evaluation,  the  control  flow  of  the  software  system  is  determined. 
We  give  another  example  which  has  a  guarded  expression  in  its  condition  part. 

Rule  rl  is 

trigger  after  updateO,   createO 
condition 

(   ssn_no  >  0    I    license.category  =  Al   ) 
action 

process_category_Al () ; 
otherwise 

process_category_general() ; 
end; 

In  the  above  example,  the  conditional  expression  in  rule  rl,  is  a  guarded  ex- 
pression.  First,  the  expression  to  the  left  side  of  '|'  (the  guard)  is  evaluated.   Note 
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a  sequence  of  guards  could  have  been  specified  and  evaluated.  If  it  is  evaluated  to 
True,  then  the  logical  expression  to  the  right  side  of  the  '|'  is  evaluated.  If  the  right 
side  is  True,  the  action  part  of  the  rule  is  executed,  or  else  the  otherwise  part  of  the 
rule  is  executed.  In  case  the  guard  is  evaluated  to  False,  then  the  rest  of  the  rule  is 
skipped,  i.e.,  neither  the  right  side  expression,  the  action,  nor  the  otherwise-clause  is 
executed. 

For  each  knowledge  base  event  that  occurs  to  instance  "this"  of  class  "X,"  all  the 
applicable  rules  will  be  triggered  (i.e.,  the  evaluation  of  the  rule  body)  according  to  the 
trigger  conditions  of  each  rule  at  either  (i)  before  the  triggering  event,  (ii)  immediately 
after  the  triggering  event,  or  (iii)  after  the  execution  of  all  the  operations  of  the  current 
transaction,  but  before  the  transaction  commits.  Thus,  our  rule  processing  system 
supports  two  types  of  coupling  modes  or  activation  policies:  namely,  the  immediate 
mode  for  "before"  and  "after"  and  the  deferred  mode  for  "on_commit." 

In  our  prototyping  system,  ECAA  rules  give  high-level  specifications  of  control 
and  logic  associated  with  program  modules  and  data  entities.  They  are  translated 
into  executable  code  and  are  activated  at  the  appropriate  time  in  relationship  with 
their  triggering  events. 

Method  Implementation:  So  far  in  this  section,  we  have  shown  that  data 
entities  as  well  as  software  components  can  be  modeled  uniformly  as  object  classes. 
We  have  already  shown  that  the  behavioral  properties  of  data  entities  and  software 
components  of  any  software  system  can  be  captured  by  methods  in  class  definitions. 
We  can  implement  a  method  body  either  by  writing  real  or  simulated  code  for  the 
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method  or  by  modeling  the  method  using  a  method  model,  which  will  be  described 
later. 

Real  or  Simulation  Code  for  Methods:  If  the  prototyper  has  a  precise 
knowledge  about  the  functionality  of  a  method  in  a  class  and  the  method  is  simple  to 
implement,  then  he/she  can  directly  write  the  implementation  code  for  the  method.  If 
the  prototyper  is  not  interested  in  or  is  not  able  to  implement  the  method,  but  rather 
wants  to  simulate  it  for  the  sake  of  testing  some  other  methods  that  depend  on  it, 
then  he/she  can  write  some  simulated  code  for  the  method.  The  simulated  code  takes 
some  input  and  provides  some  estimated  output  to  allow  the  other  methods,  which 
are  of  interest  to  the  prototyper,  to  perform  their  functionalities.  Since  K.3  combines 
general-purpose  programming  language  constructs  with  query  language  constructs 
and  offers  persistent  support  to  all  data  entities,  real  or  simulated  code  can  thus  be 
written  in  K.3. 

The  development  and  execution  of  software  systems  using  the  evolutionary  pro- 
totyping approach  are  supported  by  a  KBMS.  Any  program  execution  would  generally 
involve  the  processing  of  a  persistent  knowledge  base.  For  knowledge  base  retrieval 
and  manipulation,  a  knowledge  base  programming  language  should  include  some 
knowledge  manipulation  constructs  in  addition  to  general-purpose  programming  lan- 
guage constructs.  In  K.3  language,  we  use  pattern-based  querying  constructs  for 
retrieving  and  manipulating  the  knowledge  base.  We  use  the  context  expression  of 
an  Object-Oriented  Query  Language  (OQL)  [Ala89,  Su93]  as  the  primitive  construct 
for  specifying  the  structural  relationship  among  objects  that  are  to  be  retrieved  or 
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manipulated.  For  example,  the  expression  "CircuitMaint  !  [ctmaint]  m:MainMaint  * 
[prmaint]  pm:ProductMaint"  would  identify  all  maintenance  software  modules  (Main- 
Maint)  which  are  associated  with  some  product  maintenance  module  (ProductMaint) 
but  not  with  any  circuit  maintenance  module  (CircuitMaint).  "m"  and  "pm"  are 
variables  which  represent  the  MainMaint  and  the  ProductMaint  modules  that  satisfy 
the  above  association  pattern  specification.  "!"  and  "*"  are  non-association  and 
association  operators,  "[ctmaint]"  and  "[prmaint]"  are  the  names  of  two  attributes 
of  MainMaint  whose  values  are  the  objects  of  CircuitMaint  and  ProductMaint,  re- 
spectively. The  following  example  creates  a  circuit  maintenance  module  which  is  a 
sub-component  of  the  main  maintenance  module,  if  the  main  maintenance  module 
does  not  yet  contain  a  circuit  maintenance  module. 


context  m: MainMaint    !    [ctmaint]   CircuitMaint 
do 

cm   :=  CircuitMaint .create 0 ; 

m. ctmaint    :=  cm; 
end_context ; 


Statements  for  the  retrieval  and  manipulation  of  a  knowledge  base  may  in- 
volve existential  and  universal  quantifiers  in  forms  of  "exist  <context>  suchthat 
<boolean>"  and  "foral!  <context>  suchthat  <boolean>",  respectively  Quantifiers 
make  it  much  easier  for  the  users  to  declaratively  pose  logic  questions  upon  the  knowl- 
edge base.  For  example,  the  following  statements  display  the  product  descriptions 
of  the  products  maintained  by  the  product  maintenance  module,  which  is  a  sub- 
component of  the  main  maintenance  module,  if  the  product  description  is  non-null. 


context  m:MainMaint 

do  if  exist  p: Product  *   [product]   pm ; ProductMaint 
*    [ptmaint]    MainMaint 
suchthat  p. description    !=  null 
then 

p. desript ion. display ("'/,s\n") ; 
end.if ; 
end_context; 


As  a  computationally  complete  programming  language,  K.3  provides  some  basic 
data  structures  (set,  list,  and  array)  and  control  structures  (sequential,  testing,  repe- 
tition, and  context  looping).  We  illustrate  the  object-oriented  computation  facilities 
of  K.3  by  implementing  the  method  "get_product()"  in  class  ProductMaint. 


method  ProductMaint : :get_product()    is 
local  pcode:    Integer; 
begin 

product   :=  null; 

"\nEnter  product   code    (0=end) :    ". display (); 

pcode. readO  ; 

if  pcode   =  0  then  ■ 

return; 
end_if ; 

context  p: Product  where  p.product_code  =  pcode 
do 

product   :=  p; 

//  the  product  attribute  in  the  ProductMaint 
//  entity  is  assigned  the  proper  value 
return; 
end_context; 

"\nProduct  does  not  exist    !\n" .display () ; 
end; 
end   ; 

The  program  body  of  "get.product"  is  a  single  block  statement  "local  <  vars 
>  begin  <  statements  >  end,"  in  which,  we  define  local  variable  "pcode"  to  record 
the  product  code.  Initially,  we  read  the  product  code  from  the  user  and,  if  the  user 
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enters  a  non-zero  product  code  number,  then  we  use  the  context  looping  statement 
to  retrieve  the  product  from  the  knowledge  base  which  has  the  desired  code  num- 
ber. A  detailed  description  of  implementing  a  method  body  using  general-purpose 
programming  constructs  can  be  found  in  [Shy 96] . 
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Figure  4.1.  Control  Associations 

Method  Models:  Often  a  method  may  perform  a  complex  function,  and  is 
difficult  for  the  prototyper  to  implement  it  directly.  In  our  work,  we  extend  our  ob- 
ject model  to  support  the  modeling  of  the  method  body  in  a  uniform  manner  as  the 
modeling  of  data  entities  and  software  components.  In  the  rest  of  this  section,  we 
explain  the  modeling  of  method  bodies  to  produce  the  executable  specifications  for 
the  methods  that  are  too  complicated  to  be  implemented  directly  by  the  prototyper. 
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Our  meta  model  is  enhanced  by  the  incorporation  of  two  new  class  types,  namely 
the  CodeBlockSchema  and  the  CodeBlock.  Moreover,  a  number  of  control  associa- 
tions, namely.  Sequential,  Testing,  Case,  ForEach,  Loop,  Parallel,  Synchronization, 
and  Decomposition  (see  Figure  4.1),  are  used  to  specify  the  flow  of  control  of  a  struc- 
ture of  code-blocks  that  constitutes  a  method  implementation.  These  code-blocks 
are  modeled  by  object  classes  and  their  control  associations.  Thus,  the  prototyper 
can  model  the  method  body  of  a  complicated  method  as  a  CodeBlockSchema,  in 
which  each  code-block  class  has  an  attribute  called  source.code  for  which  the  pro- 
totyper can  provide  the  implementation  code  as  its  value  if  the  code  can  be  easily 
written.  If  a  code-block  is  still  too  complex  to  code,  then  the  prototyper  can  further 
decompose  the  code-block  and  define  it  as  a  sub-code-block-schema  which  contains 
a  structure  of  lower-level  code-blocks  linked  by  control  associations.  In  this  way, 
the  prototyper  can  gradually  evolve  a  method  implementation  by  the  above  mod- 
eling process  as  he/she  gains  more  insight  into  the  functionality  and  the  coding  of 
the  complex  method.  Since  methods  are  modeled  by  code-blocks  and  their  control 
associations,  which  corresponds  to  the  control  structures  of  any  structured  program- 
ming language,  this  modeling  technique  can  also  used  for  a  function-oriented  design 
of  software  systems.  In  this  case,  code-blocks  are  the  unit  function  building  blocks 
which  are  associated  with  one  other  by  control  associations.  Moreover,  a  prototyper 
can  specify  ECAA  rules  within  a  code-block  to  express  inter-code-block  attribute 
constraints.  For  example,  consider  two  code-block's  A  and  B.  The  prototyper  may 
want  to  specify  that  a  certain  action  needs  to  be  taken  after  executing  code-block 


B,  if  the  state  of  certain  variable  satisfied  certain  condition  before  the  code-block  A 
was  executed  the  last  time.  For  specifying  these  kind  of  inter-attribute  constraints 
between  different  code-blocks,  we  use  "paramrule"  in  the  code-block's.  These  rules 
are  termed  "paramrule"  because  their  execution  depends  on  a  number  of  parameters. 
They  are  as  follows:  1)  what  condition  needs  to  be  evaluated,  2)  the  point  in  the 
system  where  the  condition  needs  to  be  evaluated,  i.e.,  before  or  after  the  execu- 
tion of  which  code-block  and  code-block  schema,  3)  when  should  the  conditions  be 
evaluated:  i.e.,  at  which  point  of  execution,  this  information  can  be  captured  by  an 
invocation  identifier  of  the  concerned  code-block.  If  the  invocation  identifier  is  not 
specified,  then  the  last  execution  of  the  code-block  is  taken  into  consideration.  The 
triggering  of  these  rules  is  associated  with  the  execution  of  the  code-block  in  which 
they  are  defined.  The  condition  part  of  these  rules  has  a  boolean  operator  called 
"testing"  which  has  the  parameters  described  above.  The  action  and  the  alterna- 
tive action  of  the  paramrules  are  similar  to  any  ECAA  rule  used  in  classes  which 
model  data  entities  and  software  components.  A  conjunction  of  "testing"  operator 
can  be  specified  in  the  condition  part  of  these  rules  to  capture  the  inter-code-block 
integrity  constraints.  Appropriate  code  is  generated  and  attached  to  the  respective 
code-blocks  and  triggered  at  execution  time  to  realize  the  inter-code-block  attribute 
constraints.  These  rules  can  be  used  for  testing,  verification,  and  maintainance  pur- 
poses. Since  these  rules  are  specified  separately  from  the  attribute  source.code  of  the 
code-block,  they  can  capture  the  knowledge  about  the  constraints  more  explicitly, 
thus  improving  the  understandability  and  the  maintainability  of  the  target  system. 
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For  example,  the  add-product()  method  of  the  ProductMaint  class  can  be  modeled 
by  the  CodeBlockSchema  called  AddCompSchema. 


define  AddCompSchema  : 
associations: 

CodeBlockSchema 

Aggregation: 

-c 

c_no 
p_no 
Temp 

String; 
String; 
Integer 

where:      start_point    :=  "Initialization" ;//starting  code-block  name 
end;  //  of  AddCompSchema 

define  Initialization   :   CodeBlock  in  AddCompSchema 

public: 

associations: 

Sequential  -> 

{ 

seq  :  getCompInfo;  //  code-block  named  "getCompInf o" 
y  //is  sequentially  linked  to  code-block 

//  named  "Initialization" 
where:  source_code   := 
begin_text 

c_no  :=  ""; 
p_no  :=  ""; 

<  actual  code  for  fetching  a  product  > 
end_text ; 
end; 

define  getCompInfo  :  CodeBlock  in  AddCompSchema 
public  : 
associations: 
ForEach  ->  { 

Body  :  getPart; 
}  where  (CONTEXTEXPR(p:Part  where  p.part_no  =  p_no) ; 
Sequential  ->  ■[ 

seq  :  addComp; 
}; 
where:  source_code  := 
begin_text 
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<  actual  code  to  interactively  enter  the 
component  information  and  the 
environment  temperature  in  variable  Temp. 
Also  check  to  see  if  the  pairt  into  which  the 
component  is  to  be  inserted  is  null  or 
not .  If  it  is  null  then  the  method 
terminates> 
end_text ; 
end; 

define  getPart  :  CodeBlock  in  AddCompSchema 
public  : 

where:  source_code  := 
begin_text 

<  actual  code  for  assigning  part  > 
end_text ; 

end; 

define  addComp  :  CodeBlock  in  AddCompSchema 
where:  source_code  := 
begin_text 

<  code  to  add  a  component  > 
end_text; 
rules : 
paramrule  VerifylnsertionProcess  is 

triggered  after  execute  0  ^ 

condition 

testingCout, AddCompSchema,  getCompInf o , "Temp  =  SUITABLE") 
and  testingCout, ProdAddCompSchema,  insertComp, 

" insert ion_process=SUCCESS") 
action 

"insertion  of  component  is  successful\n" .display 0 ; 
otherwise 

<  code  to  control  the  environment  temperature 

to  enable  addition  of  the  component  if  Temp  is 
UNSUITABLE  else  try  to  reinsert  the  component  > 
end; 


The  add_comp()  method  in  Product  class  which  is  a  data  entity  can  also  be 
modeled  in  our  knowledge  model  by  the  ProdAddCompSchema. 
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define  ProdAddCompSchema  ;  CodeBlockSchema 

public: 

associations: 

Aggregation: 

■C 

c  :  Component ; 

insertion_process  :  Integer; 
} 

where  start _point  :=  "Prodlnitialization" ; 
end; 

define  Prodlnitialization  :  CodeBlock  in  ProdAddCompSchema 

public: 

associations: 

Sequential  -> 

{ 

seq  :  insertComp; 
} 
where:  source_code  := 

begin_text 

<  Product  Initialization  code  > 

end_text ; 
end; 

define  insertComp   :   CodeBlock  in  ProdAddCompSchema 
where:   source.code    := 
begin_text 

<  code     to  insert  the  component 
in  the  Product  object  and  then 
set  variable  named  insertion_process  to  SUCCESS 
if  insertion  is  successful  > 
end_text; 
end; 


In  the  above  example,  we  see  that  the  add-Comp()  method  of  the  ProductMaint 
class  is  modeled  by  the  CodeBlockSchema  called  AddCompSchema.  This  method 
is  supposed  to  perform  the  following  functions  in  the  following  order:  1)  fetch  the 
product,  2)  get  information  about  the  part  into  which  the  component  is  supposed 
to  be  inserted,  and  the  new  component  information,  3)  check  to  see  if  the  part  into 
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which  the  component  is  to  be  inserted  is  null  or  not:  if  it  is  null,  then  the  method 
terminates;  else,  the  actual  component  insertion  function  is  performed  by  invoking 
the  add_comp()  function  of  the  Product  entity. 

The  starting  code-block  (named  Initialization)  of  the  AddCompSchema  is  spec- 
ified as  value  of  attribute  (named  start_point)  of  the  AddCompSchema.  In  this  code- 
block,  the  prototyper  can  write  the  initialization  code  and  the  code  for  fetching  the 
product,  and  then  specify  the  next  code-block  (named  getCompInfo)  that  is  to  be 
executed  by  the  Sequential  control  association.  In  the  attribute  (named  source_code) 
of  the  getCompInfo  code-block,  the  actual  implementation  code  for  obtaining  the 
new  component  information  and  the  environment  temperature  is  specified.  The 
environment  temperature  information  is  stored  in  the  variable  called  Temp.  The 
getCompInfo  code-block  is  associated  with  the  getPart  code-block  by  the  ForEach 
control  association.  The  getPart  code-block  is  executed  for  each  object  selected  by 
the  association  pattern  which  is  specified  in  the  CONTEXTEXPR  constraint  of  the 
ForEach  control  eissociation.  The  getCompInfo  code-block  is  linked  to  the  addComp 
code-block  by  the  sequential  control  association.  In  the  attribute  called  source.code 
of  the  addComp  code-block,  the  actual  call  to  the  add_comp()  method  of  the  Prod- 
uct entity  is  done.  A  paramrule  named  VerifylnsertionProcess  is  used  in  the  add- 
Comp code-block  to  specify  an  inter-code-block  attribute  constraint.  This  rule  is 
triggered  immediately  after  executing  the  addComp  code-block.  It  verifies  the  fol- 
lowing conditions:  1)  after  (the  "out"  parameter  in  the  first  testing  clause)  executing 
the  getCompInfo  code-block  of  the  AddCompSchema,  the  Temp  variable  has  a  value 
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SUITABLE,  and  2)  after  (the  "out"  parameter  in  the  second  testing  clause)  execut- 
ing the  insertComp  code-block  of  the  AddProductCompSchema,  the  insertion-process 
variable  has  a  value  SUCCESS.  If  the  condition  clause  is  evaluated  to  True,  then  the 
action  part  of  the  rule  is  executed.  Else,  the  code  in  the  otherwise  clause  is  exe- 
cuted. This  rule  is  used  to  specify  the  inter-code-block  attribute  constraint  of  the 
getCompInfo  code-block  and  the  addComp  code-block  of  the  AddCompSchema,  and 
also  the  inter-code-block  attribute  constraint  between  the  insertComp  code-block  of 
the  ProdAddCompSchema  and  the  addComp  code-block  of  the  AddCompSchema. 

Program  Generator 


Melhod  Model 
Loader 

Method 

Code  Block 
Analyzer 

Model 

Code  Generator 


T  Method  Model 


Executable  code 


Figure  4.2.  The  Program  Generator  Infrastructure 


This  methodology  of  modeling  the  implementation  of  a  complex  method  by  a 
structure  of  code-blocks  linked  by  various  control  associations  enables  the  prototyper 
to  decompose  a  complex  method  into  more  manageable  sizes  of  code,  which  can  be 
more  easily  verified  for  their  correctness  and  performance.  This  can  help  him/her 
to  isolate  the  source  of  problems  more  easily.  Moreover,  by  taking  advantage  of 
the  code-block  class  rules,  he/she  can  specify  intra-method  or  inter-code-block  con- 
straints which  facilitate  the  detailed  testing  of  the  method  implementations.   Since 
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our  prototyping  language  K.3  has  the  KBMS  support,  all  the  test  results  and  the  per- 
formance evaluation  data  can  be  stored  and  processed  by  the  KBMS  to  facilitate  the 
evaluation  process.  We  have  developed  a  Program  Generator  (see  Figure  4.2)  which 
transforms  a  method  model  into  implementation  code  in  K.3.  A  K.3  compiler  then 
translates  the  generated  K.3  code  into  executable  code  in  C+-I-.  Thus,  all  method 
model  specifications  are  executable. 

So  far  in  this  section  we  have  demonstrated  how  we  have  used  our  model  to 
model  data  entities,  software  components,  and  method  models.  We  also  model  the 
execution  context  information,  which  is  the  schema  in  which  the  execution  data 
are  stored,  using  the  same  object-oriented  semantic  model.  The  execution  context 
contains  the  user-defined  parameters  as  well  as  the  system  generated  run-time  data. 
These  context  information  are  modeled  by  entity  classes  and  associations.  We  shall 
give  the  detailed  specifications  of  these  classes  later. 

4.3     Implementation  Details  of  Code  Generation 

The  structure  of  the  Program  Generator  is  shown  in  Figure  4.2.  It  loads  the 
K.3  specifications  from  the  KB  in  bulk  and  stores  the  specifications  in  the  main 
memory  buffer.  This  bulk  loading  reduces  the  number  of  I/O  significantly  and  thereby 
speeds  up  the  overall  code  generation  process.  The  Code  Block  Analyzer  module 
parses  the  specifications  in  the  main  memory  and  builds  the  intermediate  code,  which 
represents  the  code-block  network  structure  in  the  main  memory.  The  data  structure 
for  storing  the  intermediate  code  of  a  code  block  contains  all  the  information  about  the 
aggregation  variables,  source  code,  and  main  memory  pointers  to  other  code-blocks 
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to  which  it  is  hnked  by  control  associations.    The  information  about  the  control 

associations  is  also  stored  in  the  code-block's  main  memory  data  structure.    The 

intermediate  code  also  contains  information  about  the  code-block  class's  ECAA  rules. 

The  information  about  the  code-block  class's  rules  is  stored  in  a  rule  list.    Each 

element  of  the  list  contains  the  corresponding  rule  string.  The  main  memory  structure 

of  a  code-block  is  shown  in  Figure  4.3. 
codeBlockStruct 


char*  schemaName; 

char*  className; 

char*  methodName; 

char*  codeBlockName; 

char*  sourceCode; 

ruleList*  rules;  //  code  block  class  rules 

assocArrList*  assocs; 

codeBlockS tract*  associatedCodeBlocks; 

variableList  *vList;//  aggregate  variables 

int   isSimulated; 

int   estimatedTime; 

CodeBlockStruct*  parent; 


Figure  4.3.  Intermediate  Structure  Representation  of  a  Code-block 


Finally,  the  Code  Generator  Module  generates  the  method  implementation  from 
the  intermediate  structure.  During  the  code  generation  process,  calls  are  made  to  the 
Performance  Monitor  and  the  Functionality  Tracing  Monitor  so  that  at  run-time  the 
monitors  can  monitor  the  behavior  of  the  executable  prototype,  and  collect  valuable 
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execution  data  to  be  used  for  further  analysis.  The  code  generator  also  parses  the 
code-block  class's  ECAA  rule  strings  and  generates  code  in  appropriate  places  so 
that  conditions  are  checked  before  or  after  the  execution  of  the  code-blocks.  The  fact 
that  certain  conditions  were  evaluated  to  True  is  recorded  in  a  condition  list.  Code 
is  generated  before  and  after  the  appropriate  code-blocks  in  which  ECAA  rules  are 
specified.  It  checks  the  condition  list  to  see  if  the  condition  clause  specified  in  that 
rule  is  evaluated  to  True  or  not.  If  the  condition  is  true,  then  the  action  part  (if  any) 
of  the  rule  is  executed.  Otherwise,  the  alternative  action  (if  any)  is  taken. 


CHAPTER  5 

VERIFICATION  OF  THE  FUNCTIONALITY  AND  PERFORMANCE  OF 

EVOLVING  PROTOTYPES 


5.1     Requirements 

A  simple  approach  for  verifying  the  functionality  and  the  performance  of  an 
executable  prototype  system  is  by  tracing  its  execution.  A  prototyper  needs  the 
support  of  a  computing  environment  for  following  the  execution  step  by  step,  and 
stopping  the  execution  at  any  particular  point  in  the  code  so  that  he/she  can  check 
the  variables  which  are  in  the  visible  scope  of  that  point.  It  would  also  be  desirable  to 
generate  the  performance  profile  information,  which  includes  the  information  about 
how  much  time  different  parts  of  the  system  took  to  execute.  This  profile  information 
may  include  the  time  taken  to  execute  different  methods  or  parts  of  these  methods. 
It  would  help  the  prototyper  to  go  back  and  find  out  the  bottleneck  of  the  prototype 
after  its  execution. 

In  an  object-oriented  software  system,  in  which  the  data  entities,  software  com- 
ponents, and  method  implementations  are  all  modeled  uniformly  in  terms  of  objects, 
it  would  be  useful  to  analyze  and  understand  the  interactions  between  objects,  and 
the  state  of  the  objects  before  and  after  their  interactions.  The  various  parameters 
of  interest  which  are  either  system-tracted  or  user-determined  should  be  monitored 
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at  run-time  and  stored  in  a  structured  manner  in  the  knowledge  base  for  further 
processing  and  analysis.  These  monitored  data  represent  low-level  behavioral  infor- 
mation and  are  not  always  readily  useful  for  analyzing  the  system  behavior.  It  would 
be  very  helpful  to  the  prototyper  to  have  an  automated  process  which  can  further 
analyze  the  monitored  data  to  derive  useful  high-level  information  about  the  system 
behavior  as  well  as  to  compare  the  expected  behavior  of  the  system  against  the  actual 
observered  behavior.  These  automated  supports  would  make  the  job  of  evaluating 
the  evolving  prototypes  much  easier  for  the  prototyper. 

5.2     Mechanisms 

We  have  developed  three  mechanisms  to  support  the  requirements  mentioned 
in  the  previous  section.  First,  we  provide  a  monitoring  mechanism  for  tracing  the 
execution  of  a  system  at  the  code-block  level  and  the  method  level.  The  performance 
profiling  is  also  done  at  both  levels.  The  performance  data  collected  are  stored  in 
the  knowledge  base  just  like  the  other  application  objects  discussed  in  the  previous 
chapters.  We  use  the  object  model  discussed  in  Chapter  4  to  model  the  control  infor- 
mation, which  keep  track  of  the  states  of  different  objects  and  interaction  parameters 
between  objects  of  interest  to  the  prototyper.  These  control  object  instances  are 
stored  in  the  knowledge  base  for  further  processing  and  analysis.  We  have  developed 
a  technique  to  generate  the  control  object  instances  at  run-time  whenever  an  object 
interaction  of  interest  takes  place  or  an  object's  state  of  interest  is  modified.  The 
modeling  and  the  generation  of  the  control  instances  are  specified  by  the  prototyper. 
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He/she  determines  which  parts  of  the  system  are  to  be  monitored,  and  what  specific 
items  need  to  be  monitored. 

Secondly  we  provide  a  behavior  abstraction  mechanism  to  derive  more  useful 
information  about  the  behavior  of  system  at  run-time  based  on  the  monitored  data. 
By  an  automated  behavior  abstraction  process  using  deductive/inferencing  rules  (see 
BNF  in  Appendix  A),  high-level  information  can  be  generated  from  the  low-level 
monitored  data  generated  by  the  system.  These  high-level  information  are  much 
more  meaningful  to  the  prototyper  than  the  low-level  monitored  data.  Although, 
they  can  be  deduced  by  the  prototyper  by  examining  the  system  generated  monitor 
data  directly  and  applying  his/her  inferencing  logic,  it  will  be  much  better  if  some 
system  support  is  available  to  automate  this  process  by  incrementally  updating  the 
memory  of  the  system  as  events  occur  in  the  system,  and  detecting  typical  state 
scenarios  as  soon  as  they  occur. 

Thirdly,  we  provide  a  behavior  analysis  mechanism  to  allow  the  prototyper  to 
specify  constraints  amongst  different  control  entities  so  that  state  conditions  of  inter- 
est can  be  detected  and  some  pre-specified  actions  can  be  taken  when  such  conditions 
are  detected.  This  is  very  useful  for  checking  if  the  system  is  behaving  as  desired  or 
not.  We  allow  the  prototyper  to  specify  what  behavior  is  expected,  and  what  is  not 
expected  of  the  system.  Monitoring  and  behavior  abstraction  mechanisms  generate 
information  about  the  actual  behaviors  of  the  system,  which  is  then  matched  with  the 
specifications  of  desired  or  undesired  behaviors,  to  carry  out  the  behavior  analysis. 
A  simple  example  on  the  use  of  the  above  mechanisms  is  as  follows.  Let  us  consider  a 
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system  S  with  components  A,  B,  and  C.  In  the  object-oriented  modeling  paradigm,  S, 
A,  B,  and  C  are  all  modeled  as  first  class  objects,  where  A,  B  and  C  are  sub-objects 
or  components  of  S.  We  want  a  prototyper  to  be  able  to  specify  that,  at  any  point  of 
execution  of  the  above  system,  if  the  different  components  interact  with  one  another 
in  a  specific  sequence  and  the  interaction  parameters  satisfy  some  specific  condition, 
it  represents  an  incorrect  execution  of  the  system.  The  specification  is:  if  object  B 
invoked  method  Ml  of  object  A  before  object  A  invoked  method  M2  of  object  C, 
and  the  state  of  object  A  at  the  point  of  an  interaction  with  object  C  is  the  same 
as  the  state  of  object  B  at  the  point  of  an  interaction  with  object  A,  then  system 
S  is  not  operating  as  desired.  In  order  to  identify  such  an  execution  scenario  and 
take  necessary  action  automatically,  the  prototyping  system  needs  to  (1)  monitor  the 
interactions  between  objects  of  A,  B  and  C  and  keep  track  of  their  states,  and  (2) 
based  on  the  monitored  data,  infer  whether  they  satisfy  the  temporal  relationship 
and  data  conditions  which  constitute  an  incorrect  execution.  The  step  2  involves 
abstraction  and  analysis  of  the  monitored  data  gathered  in  step  1. 

5.3     Techniques 

We  use  different  techniques  to  implement  the  above  three  mechanisms.  A  Func- 
tionality Tracing  Monitor  (FTM)  has  been  implemented  to  support  the  tracing  of 
the  system  execution  at  the  code-block  level  as  well  as  the  method  level.  During 
code  generation,  calls  to  the  Functionality  Tracing  Monitor  are  embedded  in  selected 
places  so  that  it  is  always  aware  of  which  code-blocks  or  methods  are  under  execu- 
tion.  The  break-point  information  are  stored  as  object  instemces  in  the  knowledge 
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base  and,  whenever  the  control  reaches  a  break-point,  the  execution  can  be  halted  by 
using  the  information  generated  by  the  FTM.  To  carry  out  the  performance  profiling, 
a  Performance  Monitor  (PM)  has  been  implemented,  and  calls  to  this  monitor  are 
embedded  in  the  methods  and  the  code-blocks  at  the  time  of  code  generation.  The 
PM  keeps  track  of  the  time  taken  to  execute  a  certain  code  block  or  method  in  a 
particular  execution  and  also  the  time  taken  in  different  invocations  of  a  particular 
execution.  This  profile  information  is  of  great  help  to  the  prototyper  for  figuring  out 
the  bottleneck  of  the  system,  in  case  the  performance  of  the  system  is  not  as  desired. 

We  use  our  object  model  described  in  the  previous  chapter  to  model  the  control 
information  which  consists  of  information  about  the  low-level  system  behavior.  The 
behavior  information  mainly  consists  of  inter-object  interaction  information,  and  ob- 
ject state  information  before  and/or  after  interactions  with  other  objects.  The  control 
object  instances  are  made  up  of  user  contextual  information  and  system  contextual 
information.  Details  of  these  interaction  contextual  parameters  will  be  discussed  in 
the  next  chapter. 

The  generation  of  monitored  data  is  based  on  some  ECAA  Rules.  These  rules 
are  called  monitor  rules.  They  are  triggered  by  invocations  of  the  methods  that  the 
prototyper  wants  to  monitor.  These  rule  are  specified  by  the  prototyper  so  that  the 
monitored  data  are  gathered  according  to  the  specification  of  the  prototyper.  More 
details  on  the  generation  of  the  monitored  data  and  the  monitor  rule  specification 
and  implementation  will  be  given  in  the  next  chapter. 
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The  support  for  processing  inferencing  rules  has  been  implemented  so  that  the 
prototyper  can  specify  behavior  abstraction  logics  and  the  behavior  analysis  logics 
in  a  declarative  manner.  The  implemented  system  automates  the  execution  of  these 
rules  as  the  monitored  data  are  gathered  at  run-time.  The  chained  triggering  of  these 
deductive  rules  implements  the  mechanisms  of  behavior  abstraction  and  behavior 
analysis.  In  Chapter  7,  we  will  discuss  in  detail  the  specification  and  implementation 
of  these  rules. 


CHAPTER  6 
ECAA-RULE-BASED  MONITORING  OF  SYSTEM  BEHAVIOR 


In  order  to  understand  the  behavior  of  a  target  system  under  development,  we 
must  have  some  means  of  monitoring  the  system  behavior  at  run-time.  The  behav- 
ioral information  includes  both  its  functionalities  and  performance.  We  identified 
two  kinds  of  context  that  are  of  interest  at  system  execution  time.  They  are  the  user 
context  and  the  system  context.  The  user  context  contains  the  information  provided 
as  parameters  by  the  prototyper  whereas  the  system  context  is  made  up  of  control 
information,  which  include  the  caller  context,  the  callee  context,  the  execution  time, 
and  the  invocation  information  automatically  generated  by  the  system  at  run-time. 

In  order  to  collect  the  user  context  and  associate  them  with  the  system  context 
information,  active  ECAA  rules  are  used.  These  rules  are  specified  by  the  proto- 
typer when  a  prototype  system  is  modeled  and  triggered  before  or  immediately  after 
the  execution  of  some  specified  methods  to  generate  the  user  context  information  and 
associate  them  with  the  corresponding  system  context  information.  These  context  in- 
formation are  stored  as  instances  of  object  classes  which  model  the  user's  contextual 
views.  The  instances  of  these  "execution  context"  classes  are  generated  by  active 
rules.  They  represent  the  low-level  system  behaviors  which  deal  with  inter-object 
interactions.   These  active  rules  are  specified  in  entity  classes  that  model  program 
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modules  and  code-blocks  and  are  triggered  to  gather  both  performance  and  function- 
ality data  at  run-time.  They  can  be  used  to  perform  selective  monitoring,  i.e.  the 
prototyper  can  use  them  to  monitor  whichever  part  of  the  system  he/she  wants  to 
monitor.  In  a  later  section  in  this  chapter,  we  shall  give  some  examples  of  their  use. 

Since  the  execution  of  any  target  system  progresses  with  time,  we  consider  time 
to  be  an  important  dimension  m  any  kind  of  analysis  of  the  target  system's  behavior. 
In  order  to  take  the  temporal  dimension  into  consideration,  we  have  incorporated 
the  Start-time,  and  End-time  concepts  within  each  of  the  execution  context  record. 
Thus,  each  instance  of  an  execution  context  class  will  have  these  two  time  attributes 
associated  with  it.  Start-time  records  the  time  of  the  creation  of  that  execution 
record,  whereas  End-time  records  the  end  of  a  valid  time  interval. 

Besides  the  incorporation  of  the  time  component  into  the  structure  of  the  ex- 
ecution context  information,  we  have  incorporated  the  following  operators  in  our 
prototyping  language: 

1)  (last  instance)  :    returns  the  last  version  of  the  instance,  or  null  if  such  an 
instance  does  not  exist. 

2)  (first  instance)  :   returns  the  first  version  of  the  instance,  or  null  if  such  an 
instance  does  not  exist. 

3)  (nth  instance)  :    returns  the  nth  version  of  the  instance,  or  null  if  such  an 
instance  does  not  exist. 

4)  (last  className)  :  returns  the  last  instance  of  className  or  null. 
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5)  (first  className)  :  returns  the  first  instance  of  className  or  null. 

6)  (nth  className)  :  returns  the  nth  instance  of  className  or  null. 

7)  temporal_function(classinstance)  ;  temporal_function  can  be  STARTTIME, 
ENDTIME,  or  INTERVAL  function.  It  returns  the  appropriate  time  value 
(depending  on  the  actual  function  called)  of  the  class  instance,  or  null  in  case 
the  classJnstance  is  null. 

8)  temporal_function(classJnstancel)  Before  temporal_function(classJnstance2)  : 
this  expression  returns  true  if  the  time  value  returned  by  temporal_function(cla- 
ssJnstancel)  is  earlier  (or  smaller)  than  that  of  temporal_function(classJnstan- 
ce2).  Otherwise,  it  returns  false  if  either  of  the  temporal  functions  evaluates  to 
null,  or  the  Before  condition  is  not  true. 

9)  temporalJunction(classinstancel)  After  temporal_function(classJnstance2)  : 
this  expression  returns  true  if  the  time  value  returned  by  temporalJ'unction(cla- 
ssJnstancel)  is  later  (or  greater)  than  that  of  temporal_function(classJnstan- 
ce2).  Otherwise  it  returns  false  if  either  of  the  temporal  functions  evaluates  to 
null,  or  the  After  condition  is  not  true. 

10)  temporal_function(classJnstancel)  When  temporal_function(classJnstance2)  ; 
this  expression  returns  true  if  the  intervals,  in  which  the  classJnstancel  and 
class  Jnstance2  are  valid,  overlap  each  other.  Otherwise  it  returns  false  if  either 
of  the  temporal  functions  evaluates  to  null,  or  the  intervals  do  not  overlap. 
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11)  temporal-function(classJnstancel)  -  temporal_function(classJnstance2)  :  this 
expression  returns  the  difference  in  time  between  the  two  class  instances.  If  one 
of  the  operands  is  the  INTERVAL  function,  then  the  other  has  to  be  INTERVAL 
function  also. 

12)  NOW  :  returns  the  current  time. 

13)  classJnstance. (boolean  expression)  :  this  expression  returns  the  classJnstance 
if  the  boolean  expression  evaluates  to  true  on  that  class  instance.  Otherwise,  a 
null  is  returned. 

14)  classJnstance. fieldjiame  :  returns  the  field.value. 

15)  classjiame.  (assignment  statements)  :  creates  a  class  instance  with  the  appro- 
priate values. 

16)  (exists  variableiclassName). (qualifiers)  :  this  expression  returns  true  if  an  in- 
stance of  the  named  class  exists  and  satisfies  the  qualifiers.  Otherwise,  it  returns 
false.  In  case  the  above  expression  returns  true,  the  variable  refers  to  the  class 
instance  which  satisfies  the  qualifiers. 

17)  classJnstance. init_className(field  values,systemContext)  :  initializes  the  speci- 
fied instance  with  the  specified  values,  and  also  populates  the  associated  system 
context  passed  as  a  parameter  with  the  appropriate  values,  containing  the  caller 
context  and  the  callee  context  which  will  be  elaborated  later  on  in  this  chapter. 

In  the  above  list  of  temporal  operators  and  functions,  the  last  instance  refers 
to  the  one  which  has  the  largest  STARTTIME  value.  The  temporal  Junction  above 
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can  be  either  STARTTIME,  ENDTIME,  or  INTERVAL,  while  NOW  returns  the 
current  time  value.  The  last,  first,  nth  operators  have  higher  precedence  over  the 
'dot'  operator.  For  example  the  expression  (last  className). (boolean  expression)  is 
processed  as  follows.  First  of  all,  the  (last  className)  returns  the  last  class  instance. 
Then,  the  boolean  expression  which  can  be  a  conjunction  of  boolean  expressions  is 
evaluated  on  that  class  instance.  The  result  of  this  evaluation  is  either  the  class 
instance  or  null.  In  the  former  case,  the  expression  is  evaluated  to  true  with  respect 
to  the  instance.  In  the  latter  case,  it  evaluates  to  false. 

In  the  next  chapter,  we  will  see  some  examples  of  the  state-based  inferencing 
rules  where  some  of  the  above  functions  are  used.  The  incorporation  of  the  above 
functions  enhances  the  expressive  power  of  our  prototyping  language. 

6.1     Capturing  the  Execution  Data  in  the  Knowledge  Model 

At  run-time,  whenever  a  method  is  executed,  there  are  two  kinds  of  information 
that  are  of  interest.  One  is  the  prototyper  supplied  parameters,  e.g.  the  parameters 
of  inter-class  or  inter-method  interactions,  whose  types  and  names  are  determined  by 
the  prototyper  at  the  system  specification  time.  The  other  is  the  system  evaluated 
parameters  which  are  generated  by  the  system  at  run-time.  The  system  context  at 
any  point  of  system  execution  includes  the  information  about  from  where  the  control 
came  from,  the  time  when  the  interaction  took  place,  and  the  total  time  during 
which  the  interaction  lasted  (which  is  the  time  taken  by  the  method  to  execute 
in  the  current  invocation),  the  number  of  invocation  of  this  method  prior  to  the 
current  invocation,  etc.  All  these  information  are  very  useful  for  understanding  the 


59 

system  behavior  and  performance,  and  for  detecting  the  bottlenecks  and  problems 
of  the  system.  These  contextual  information  are  stored  as  instances  of  object  classes 
modeled  by  the  same  model  used  for  modeling  data  entities,  system  components, 
and  method  implementations.  We  generate  both  the  user  context  and  the  system 
context  based  on  active  ECAA  rules  specified  by  the  prototyper.  These  rules  are 
triggered  either  before  or  after  method  invocations.  The  execution  context  gathered 
are  stored  in  the  KB,  and  can  be  queried  by  the  prototyper  using  the  OQL  interface. 
These  execution  data  contain  useful  information  about  the  actual  functionality  of  the 
system  at  run-time  and  the  performance  results  of  the  target  system.  The  structures 
of  the  SystemContext  and  the  UserContext  entity  classes  are  given  below: 


define  SystemContext  :  Entity 

associations: 

public: 

Aggregation  -> 
{ 

callee_class_name 

:  String; 

callee_method_name 

:  String; 

caller_class_name 

:  String; 

caller_method_naiiie 

:  String; 

starttime 

:  Time; 

endt  ime 

;  Time; 

num_of .invocation 

:  Integer; 

interval 

:  Time; 

//  interval  after  which  callee  method 
//  was  invoked 
execution_time  :   Time; 

invocation.context    :    String; 

//  before  or  after  the  invocation 
//  of  callee  method  the  context 
//  was  generated 
}; 
end; 
Example  of  a  Class  representing  the  user  context   information: 
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define  UserContext   :  Entity 

associations: 

public  : 

Generalization  <-  {  SystemContext  }; 

Aggregation  -> 

i 

//Specifications   of  the  parameters 
//of  the  prototyper's   interest 
//which  may  include  the  parameters  of  a 
//method  invocation  or  the  state  of  the 
//attributes  of  the  object  at  the  point 
//of  generation  of  the  user  context; 
//These  are  modeled  by  the  application  prototyper 
//according  to  his/her  requirements  which  are 
//  governed  by  the  application  parameters. 
} 
end: 


The  information  about  the  number  of  invocations,  the  last  time  of  invocation 
by  another  method,  and  other  system  contextual  fields  are  stored  in  the  system  for 
each  method  of  each  class,  as  shown  in  Figure  6.1.  The  fields  of  the  SystemCon- 
text entity  instances  are  populated  with  system  generated  time  information  and  the 
invocation  history  for  each  method  which  capture  the  details  of  the  interclass  inter- 
action. We  note  that  the  UserContext  class  has  a  Generalization  association  with 
the  SystemContext  class,  so  that,  for  each  UserContext  record  generated,  there  is 
a  SystemContext  record  which  contains  the  control  information  at  the  point  of  the 
context  generation.  The  generation  of  these  context  records  are  triggered  by  active 
ECAA  rules  and  many  of  the  items,  which  appear  inside  the  context,  are  generated 
by  the  Performance  Monitor  (PM):  e.g.,  the  starttime,  endtime,  and  execution.time. 
These  values  that  are  monitored  by  the  PM  can  be  used  in  the  action  part  of  the 
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ECAA  rules  to  generate  the  appropriate  context  records  at  run-time.  Thus,  the  pro- 
totyping language  and  the  prototyping  environment  work  together  in  revealing  the 

actual  system  behavior  at  run-time. 

For  each  method  in  each  class  the  system  maintains  the  InvocationDetailsList 
whose  structure  is  shown  below: 


className; 

methodName; 

callerClassName; 

callerMethodName; 

self  Old; 

callerOid; 


numberOflnvTillNow ; 
lastTimeOflnvocation ; 


Unique  Id  of  the  list  Element 


Figure  6.1.  System  Information  about  the  Invocation  History  for  a  Method 

6.2     Specification  of  Monitor  Rules 
We  show  some  examples  of  monitoring  rules  below: 


define  Machine    :   Entity 

associations; 

public: 

Aggregation  -> 
{ 

state  :  Integer; 

name   :  String; 

id  :  Integer;  where  {  UNIQUE(id) ;  } 


methods : 
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public: 

method  operate (input_signal  :  Integer,  input_descriptor  :  String); 

rules : 

rule  monitor_rule_l 

triggered  before  operate(input_signal,input_descriptor) 

action 

local  m  :  MachineControl ; 
begin 
m . init_MachineControl (id , input.s  ignal .state , BEFORE_OPERATION , 
systemContext) ; 
//  init_MachineControl()  function 
//  initializes  a  MachineControl  instance 
end; 
end; 

rule  monitor_rule_2 

triggered  after  operate (input_signal,input_descriptor) 

action 

local  m  :  MachineControl; 
begin 
m . init_MachineControl (id , input_signal , state , AFTER.OPERATION, 
systemContext) ; 
end; 
end ; 

end;  //  Machine 

define  MachineControl  :  Entity 
associations: 
public: 

Generalization  <-  {  SystemContext  }; 
Aggregation  -> 
{ 

machine_id  :  Integer; 

input_signal  :  Integer; 

machine_state  :  Integer; 

time  :  Integer; 

}; 

method  init_MachineControl(machine_id  :  Integer, 

I  ,  input_signal  :  Integer, 

machine_state  :  Integer, 
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time  :  Integer, 

systemContext  :  SystemContext) ; 

//  the  body  of  the  above  init_MachineControl()  method  is 

//  automatically  generated  from  the  class  definition 

//  information  of  the  MachineControl  entity  class  stored 

//  in  the  meta  schema. 

end; 


The  method  named  operate  in  the  above  example  is  invoked  by  the  external  ob- 
jects to  operate  on  the  machine.  It  may  change  the  state  of  the  machine.  In  the  above 
example,  we  see  how  the  active  monitoring  rules,  monitor_rule_l  and  monitor_rule_2, 
can  be  used  to  monitor  the  state  of  machine  and  the  parameters  of  interaction  with 
its  caller.  The  MachineControl  entity  stores  the  control  information  of  the  Machine. 
The  control  information  consists  of  the  user  contextual  parameters  and  the  system 
contextual  parameters.  The  user  contextual  parameters  in  the  MachineControl  entity 
specify  the  machine  state,  input  signal,  machine  identifier,  and  the  time  of  generation 
of  the  control  information,  i.e.  either  before  or  after  the  operation.  The  structure 
of  the  system  context  has  already  been  discussed  before.  The  system  contextual 
parameters  contain  the  information  which  are  useful  for  system  analysis  as  we  shall 
explain  in  another  example  later  on.  The  control  information  generated  by  the  ECAA 
monitoring  rules  facilitate  the  target  system  evaluation. 

The  monitoring  rules  perform  the  following  functionalities: 

1)  Monitor  an  object's  state  and  its  interaction  with  the  external  world. 
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2)  Keep  track  of  the  last  method  of  a  particular  class  which  was  executed.  This 
information  will  guide  the  prototyper  to  determine  where  the  system  termi- 
nated. In  case  of  faulty  termination,  this  will  be  a  good  point  from  which  the 
prototyper  can  trace  back  to  find  the  error. 

3)  Gather  information  about  the  data  at  the  point  of  interaction  between  two 
objects.  This  is  very  useful  for  trapping  illegal  interaction  between  two  objects. 

4)  Gather  statistics  about  the  invocation  of  the  methods  of  different  classes.  This 
will  help  in  analyzing  the  overall  performance  of  the  system  at  a  gross  level. 

5)  Get  a  global  picture  of  the  control  flow  of  the  system  in  execution.  This  will 
help  the  prototyper  to  better  understand  the  target  system  he/she  is  trying  to 
develop. 

6.3     Implementation  of  Monitor  Rules 

As  discussed  in  the  previous  section,  the  main  function  of  the  monitor  rules  is 
to  generate  the  control  entity  instances,  at  the  point  when  interaction  takes  place  be- 
tween different  object  entities.  This  is  enabled  by  using  the  Event-Condition-Action- 
Alternative-Action  (ECAA)  Rules  in  the  following  way.  The  ECAA  rule  processor 
injects  calls  to  the  rule  handler  before  and  after  the  execution  of  every  method  on 
which  a  rule  has  been  defined.  The  rule  is  translated  into  a  method  which  we  call 
a  "rule  method."  The  rule  handler  is  responsible  for  calling  the  rule  method  which 
executes  the  condition,  action,  and  alternative  action  (CAA)  parts  of  the  rule.  Two 
different  execution  modes  are  supported  by  the  rule  processor,  namely  the  immediate 


mode  and  the  deferred  mode.  In  the  immediate  mode,  the  rule  method  is  executed 
either  before  or  after  the  execution  of  a  method,  whereas,  in  the  deferred  mode,  rules 
are  fired  at  the  transaction  commit  time. 

During  the  translation  of  the  CAA  part  of  a  rule  into  a  rule  method,  the  pa- 
rameters of  the  method  invocation  which  activates  the  rule  is  packed  into  a  generic 
parameter  list  and  passed  to  the  rule  handler.  The  rule  handler  passes  this  generic 
parameter  list  to  the  rule  method,  in  which  the  parameters  are  unpacked  and  are 
bound  to  variables  whose  names  and  types  are  the  same  as  the  method  parameters. 
This  is  how  the  visibility  of  the  method  parameters  is  implemented  within  the  rule 
method. 

For  each  method,  before  the  actual  body  of  the  method  (i.e.  the  implementa- 
tion code)  is  generated,  code  for  preparing  the  parameters  of  the  system  context  for 
that  method  is  generated.  For  example,  the  attributes  for  the  caller  class  and  the 
caller  method,  which  form  a  part  of  the  system  context,  are  assigned  the  values  of 
the  class  name  and  the  method  name  of  the  caller.  The  contextual  parameters  are 
passed  during  method  invocations  which  might  take  place  within  the  body  of  this 
method.  Also,  for  every  method,  besides  the  regular  user-defined  parameters,  there 
is  a  contextual  parameter  which  contains  the  callee's  class  name,  the  callee's  method 
name  and  the  other  invocation  parameters  as  described  earlier  in  this  chapter.  The 
K.3  compiler  generates  these  contextual  parameters  both  during  the  generation  of 
the  method  signature  as  well  as  during  the  generation  of  the  method  invocations. 
These  contextual  parameters  are  hence  passed  to  the  rule  method  by  the  mechanism 


of  parameter  packing  and  unpacking  as  discussed  in  the  previous  paragraph.  Thus, 
the  contextual  parameters  also  become  visible  within  the  rule  method.  Thus,  the 
control  entity  instances  can  be  generated  from  the  ECAA  monitoring  rules.  They 
contain  the  user  contextual  parameters  and  the  system  contextual  parameters.  We 
will  now  explain  the  translation  of  ECAA  rules  into  executable  C++  code  with  an 
example.  The  following  is  the  specification  of  a  typical  class  definition  in  K.3: 


define  A   :   Entity 

associations: 

public: 

//  assoc  definitions 

methods : 

public : 

method  mK  paraml  :  Typel,  param2  :  Type2,  ....) 

//  body  of  method  ml  in  K.3 

end; 

//  other  methods  of  class  A 

rules : 

rule  rl  is 

triggered  before  ml (param_ objects  of  method  ml), 

after  ml(param_objects  of  method  ml) 
condition  <  condition  expression  > 
action 

<procedural  K.3  code  > 
otherwise 

<procedural  K.3  code  > 
end; 

//  other  rules  of  class  A 

end; 
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K  class  A  specidcalion  contaiiUng  method  ml 


KJ  COMPILER 


C++  code  generated  to  implement  the  ECAA  rule 


_KCLASS_A::nil(  parameter  objects. 
caller  conlexl  object) 


_KCLASS_A::_KBECIN_m)(parameler  objects, 
context  object) 


I.  code  to  prepare  a  generic  parameter 
list  containing  parameter  objects  and 
context  object .  call  it  _KpList 
2.call  _KRuleHandler::lrigger_nile< 
rak  method  function _ptr«bjecl_plr  of  A, 
iKpLUtf  J     -F   -    -". 


_KCLASS_A::_KEND_mI(  parameter  objects, 
cnnlMt-oh^etU 


1.  code  to  prepare  a  generic  parameter 
list  containing  parameter  objects  and 
context  object  ,  call  It  _KpList 
2.cmll  _KRuleIlandler::trlgger_rule< 
nile_mrthod_fun€tion_ptr,  «biect_plr_of_A, 
_KpLlsl) 


,KRi  lcHani»cn:lr^ger_ 


1.  call  the  Performance  Monitor  <PM) 
and  Functional  it]'  Tracing 
Monitor  (FTM) 
2.caH_KBEGEN_ml( 

parameter  objects, 

caller  context  object) 

3.  code  U>  prepare  its  context  object 
so  that  it  can  be  passed  to  method 

In vocatwns  made  inside  body  of  ml. 

4.  Actual  tMidy  of  the  method    ml 

5.  call  _KEND_ml(parameter  objects, 
caller  context  object) 

6.  call  the  Performance  Monitor  (PM) 
and  Funclionalit]'  Tracing 
Monitor  (FTM)  


(6) 

E<rule_inelbod_ptr.  object_plr, 
gen  eri  c_  pa  rameter_l  Isi ) 


_KCLASS_A::rl(object_ptr,  generic  parameter  list) 


1.  unpack  parameter  list  and  bind  values  to  local 
variables  whose  names  and  types  are  the  same 
as  those  specined  In  the  method  signature 

2.  body  of  the  rule  method - -- 

Note:  the  method  parameter  and  the  context 
object  are  visible  within  the  body  of  this  method 
so  they  can  be  captured  within  the  monitored  data 


rule  method  body 

containing 

the  code  for 


the  CAA  part  of  the 
ECAA  rule 


Figure  6.2.  The  Translation  Mechanism  to  Implement  ECAA  Rules 
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In  the  above  example,  we  show  the  definition  of  a  typical  class  A,  with  method 
ml()  and  ECAA  rule  rl  which  is  to  be  triggered  before  and  after  invocation  of  method 
ml()  to  check  whether  certain  conditions  are  satisfied  before  and  after  invocation  of 
ml().  The  class  A  in  K.3  language  is  compiled  into  a  C++  class  called  J<CLASS_A, 
and  the  ECAA  rule  and  method  specifications  are  compiled  into  C++  methods  of  that 
class  as  shown  in  Figure  6.2.  The  Performance  Monitor  (PM)  and  the  Functionality 
Trace  Monitor  (FTM)  are  invoked  in  the  beginning  of  method  ml()  (see  link  1  in  Fig- 
ure 6.2).  They  keep  track  of  the  execution  profile  information.  The  _KBEGIN_ml() 
method  is  then  invoked  (see  link  2).  The  parameter  objects  of  method  ml()  and 
the  caller  context  object  of  method  ml()  are  passed  to  the  _KBEGIN_ml()  method. 
Within  the  body  of  the  _KBEGINjnl(),  a  generic  parameter  list  is  created  containing 
the  parameters  of  the  method  ml()  and  the  caller  context  object  of  method  ml(). 
A  pointer  to  this  generic  parameter  list,  a  pointer  to  class  A  object  and  a  pointer 
to  the  rule  method  for  rule  rl  are  passed  to  the  trigger_rule  method  of  the  Rule 
Handler  class  (see  link  3).  The  Rule  Handler  is  a  component  of  the  KBMS.  The 
application  classes  that  constitute  the  prototype  system  make  use  of  the  service  of 
the  Rule  Handler.  The  trigger_rule  method  of  the  Rule  Handler  applies  the  generic 
parameter  list  and  the  class  A  object  pointer  to  the  rule  method  (see  link  4).  Thus, 
the  rule  method  for  rule  rl  gets  executed  before  the  execution  of  method  ml.  Since 
the  generic  parameter  list,  and  the  pointer  to  the  object  of  class  A  are  passed  to  the 
rule  method,  they  are  visible  within  its  body.  The  generic  parameter  list  is  unpacked 
and  the  binding  to  the  local  variables  takes  place.    These  variables  have  the  same 


names,  types,  and  values  as  the  parameters  of  method  ml().  Thus,  the  visibility  of 
the  method  parameters  and  the  contextual  parameters  within  the  rule  method  body 
enables  these  parameters  to  be  captured  as  a  part  of  the  monitored  data.  The  invo- 
cation of  the  rule  method  of  rl  after  the  execution  of  ml()  takes  place  in  a  similar 
fashion  (see  links  5,  6,  7).  Finally,  a  call  is  made  again  to  the  two  Monitors  to  notify 
them  of  the  end  of  ml()  execution  (see  link  8). 

Within  the  rule  method,  code  is  generated  to  compute  the  start  time  of  invo- 
cation, the  end  time  of  invocation,  and  some  other  parameters  such  as  the  interval, 
and  the  number  of  invocation  as  discussed  in  Section  6.1.  These  information  are 
derived  from  the  system  stored  information  as  shown  in  Figure  6.1.  These  contextual 
parameters  can  be  passed  into  the  control  entity  instances,  which  constitute  the  data 
generated  based  on  the  monitoring  rules,  so  that  further  inferencing  and  analysis  can 
be  done  based  on  these  contextual  information.  The  processes  of  behavior  abstraction 
and  behavior  analysis  are  the  topics  of  discussion  in  the  next  chapter. 

To  support  the  generation  of  the  control  entity  instances  for  each  control  entity 
class  named  X,  a  method  definition  of  init_X(parameters)  is  automatically  generated 
using  the  attributes  of  X  so  that  the  prototyper  only  needs  to  invoke  init-X()  to 
generate  the  monitored  data  of  his/her  interest.  The  method  init-X()  actually  does 
the  instantiation  of  instances  of  class  X. 


CHAPTER  7 
INFERRING  OF  SYSTEM  BEHAVIOR  USING  DEDUCTIVE  RULES 


So  far  in  this  dissertation,  we  have  discussed  the  use  of  ECAA  monitoring  rules 
for  gathering  run-time  contextual  information.  These  rules  are  attached  to  some 
class  and  are  event-based  and  procedural  as  they  are  triggered  when  some  methods 
of  some  object  classes  are  invoked.  Since  these  rules  are  triggered  by  events  which 
are  method  invocations,  contextual  information  can  be  gathered  at  the  points  of 
method  invocations.  The  data  gathered  are  low-level  data  representing  a  system's 
execution  behaviors.  It  is  useful  to  provide  a  state-based  rule  specification  facility 
to  allow  the  prototyper  to  state  that,  if  the  states  of  some  object  instances  exist, 
then  the  states  of  some  other  object  instances  should  also  exist.  This  type  of  rules 
are  high-level,  declarative,  and  deductive  rules  each  of  which  has  an  antecedent  and 
a  consequent.  The  antecedent  consists  of  data  conditions  that  involve  a  single  or 
multiple  object  instances.  Whenever  the  antecedent  is  evaluated  to  true,  it  implies 
that  the  consequent  part  of  the  rule  is  also  true.  We  implemented  and  enforced  the 
semantics  of  inferencing  rules  by  translating  them  into  entity  classes  having  active 
ECAA  rules  and  methods  for  testing  the  antecedent  part,  and  for  executing  the 
consequent  part  of  these  rules.  The  active  rules  and  methods  are  then  transformed 
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into  executable  C++  code.  The  details  of  the  implementation  strategy  is  discussed 
in  a  Section  7.4  of  this  chapter. 

7.1     Specification  of  Deductive  Rules 

In  the  previous  chapter,  we  have  shown  how  the  active  monitoring  rules  gener- 
ated the  run-time  execution  data.  In  some  situations,  the  data  may  be  too  low-level 
and  too  detailed.  They  may  not  be  of  much  use  to  the  prototyper.  However,  a  col- 
lection of  them  satisfying  some  constraints  determined  by  the  application  logic  may 
represent  a  behavior  scenario  of  the  target  system  that  is  of  interest  to  the  prototyper. 
In  the  following  example,  temporal  operators  discussed  earlier  in  this  dissertation  are 
used  in  the  deductive  rules. 


define   InputDevice    :   Entity   in  EngineSchema 

associations: 

public: 

Aggregation  ->  { 

state  :  Integer; 

fuel_level:  Integer; 

power_level  :  Integer; 

name  :  String; 
}; 
end; 


define  OuputDevice:  Entity  in  EngineSchema 
associations: 
public : 
Aggregation  ->  { 

state  :  Integer; 

name   :  String; 

output  :  String; 

temperature  :  Real ; 
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pressure  :  Real; 
}; 
end; 

define  Processor  ;  Entity  in  EngineSchema 

associations: 

public: 

Aggregation  ->  { 

state  :  Integer; 

power  :  Boolean; 

version_no  :  Integer; 

temperature  :  Real ; 

}; 


end; 


define  InputDeviceControl  :  Entity  in  EngineSchema 

association: 

public: 

Generalization  <-   {  SystemContext  }; 

Aggregation  ->  { 

engine_id  :  Integer; 
state  :  Integer; 
fuel_level  :  Integer; 
input_signal  :  Integer; 
signal_rate  :  Real ; 
}; 
methods : 
public: 

method  init_InputDeviceControl(engine_id   :  Integer, 

state  :  Integer, 
fuel_level  :  Integer, 
input_signal : Integer , 
signal_rate:Real 
SystemContext  :  SystemContext); 
end; 

define  OutputDeviceControl  :  Entity  in  EngineSchema 

association: 

public : 

Generalization  <-   {  SystemContext  }; 

Aggregation  ->  { 

engine_id  :  Integer; 

state  :  Integer; 
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temperature  :  Real ; 
external_temperature  :  Real; 
}; 
methods : 
public: 

method  init_OutputDeviceControl(engine_id  ;  Integer, 

state  :  Integer, 
temperature  :  Real, 
external_temperature  :  Real , 
systemContext rSystemContext) ; 
end; 

define  ProcessorControl  :  Entity  in  EngineSchema 

association: 

public: 

Generalization  <-   {  SystemContext  }; 

Aggregation  ->  { 

engine_id  :  Integer; 
state  :  Integer; 
power  :  Boolean; 
temperature  :  Integer ; 
}; 
method  init_ProcessorControl(engine_id   :  Integer, 

state  :  Integer, 
power  :  Boolean, 
temperature  :  Integer, 
systemContext : SystemContext) ; 
end; 

define  Engine  :  Entity  in  EngineSchema 

associations: 

public: 

Aggregation  ->  { 

id  :  Integer;  where  {  UNIQUE ( id) ;  } 

input .component  :  InputDevice; 

output_component :  OutputDevice; 

core_component  :  Processor; 

name  :  String; 

state  :  Integer; 
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methods : 
public: 

//These  methods  can  affect  the  state  of  different 
//components  of  a  Engine  in  various  ways.  The  prototyper 
//is  responsible  for  implementing  the  functionality  of 
//these  methods.  For  evaluation  purpose,  in  order  to  see 
//whether  the  methods  are  performing  their  functions  properly 
//the  prototyper  can  define  the  monitoring  rules  to  extract 
//the  execution  data  at  run  time,  and  deductive  rules  to 
//identify  the  defect  and  the  faults  of  the  system. 

public: 

method  process_input(input_signal  :  Integer, 
signal_rate  :  Real, 
processor_connection: String) ; 

//  this  method  could  affect  the  state  of  InputDevice 

//  and  Processor 

method  extract_output(external_temperature  :  Real, 

processor_connection  : String); 

//  this  method  could  affect  the  state  of  OutputDevice 

//  and  Processor  these  method  can  be  invoked  by  other 

//  objects  to  operate  on  the  Engine  Entity 

rules ; 

rule  monitor_rulel 

triggered  after  process_input  (input_signal,signal_rate, 

processor_connection) 
condition  input_component .state=  ON 
action 

local 

al  :  InputDeviceControl, 
a2  :  ProcessorControl; 
begin 

a2 . init_ProcessorControl (id , output_coraponent . state , 
processor .power,  processor_connection,  systemContext) ; 
al .  init_InputDeviceControl (id , input.component . state , 
input_component . f uel_level , 
input_signal,  signal_rate,  systemContext); 
end; 
end; 

rule  monitor_rule2 

triggered  after  extract_output(external_temperature, 

processor_connection) 
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condition  core_component .state  =  ON 
action 

local 

a4  :  ProcessorControl,  .  • 

a3  :  DutputDeviceControl; 
begin 

a4 . init_ProcessorControl (id , processor . state , 
processor .power ,  processor_connection,  systemContext) ; 
if (output_component. state  =  ON)  then 

a3 . init_OutputDeviceControl ( id , output_component .state , 
output_component .temperature, 
external_temperature ,  systemContext) ; 
end_if ; 
end; 
end; 

end;  //  of  Engine  Entity 

define  ActualEngineStatus  ;  Entity  in  EngineSchema 

associations: 

public : 

Generalization  <-  {  SystemContext  }; 

Aggregation  ->   { 

id  :  Integer; 

power  :  Boolean; 

temperature  :  Integer; 
}; 

end; 


define  ExpectedEngineStatus  :  Entity  in  EngineSchema 

associations: 

public: 

Generalization  <-  {  SystemContext  }; 

Aggregation  ->  { 

engine_id   :  Integer; 

temperature  :  String; 

}; 

end; 

define  AffectedClient  :  Entity  in  EngineSchema 
associations: 
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public: 

Generalization  <-  {  SystemContext  }; 

Aggregation  ->  { 

client_class  :  String; 

server_engine  :  Integer; 


}; 


end; 


define  EngineSchema  :  Schema 

rules: 

//  rulel  carries  out  behavior  abstraction 

deductive_rule  rulel 

eintecedents 

(  (STARTTIHE  (last  pc_inst :ProcessorControl) . 

(state  =  ON,  temperature  <  oc_inst .temperature)) 

Before 

(STARTTIHE  (last  ic_inst :InputDeviceControl) . 

(engine_id  =  pc.inst .engine_id,  state  =  ON)) 

)  and 

(exist  oc.inst : OutputDeviceControl . 

(external_temperature  >  THRESHOLD , engine  id=pc_inst .id) 

) 
consequents 

ActualEngineStatus. (machine_id  :=  pc_inst.id, 
power  :=  pc.inst .power, 
temperature  :=  oc_inst .temperature, 
caller.class  :=  ic_inst .caller.class) 
end; 

//  rule2  carries  out  behavior  analysis 
deductive_rule  rule2 
antecedents 
(exist  a_inst: ActualEngineStatus. temperature 
>  e_inst .temperature)  and 
(exist  e_inst:ExpectedEngineStatus.id 

=  a_inst .machine_id) 
consequents 

AffectedClient . (client_class  := 
a_inst . caller_class , 
server_engine  :=  a_inst.engine_id) 
end; 
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end;   //  EngineSchema 

In  the  above  example,  we  have  shown  the  specification  of  an  EngineSchema.  The 
Engine  entity  is  made  up  of  core_component,  input_component,  and  output-component. 
The  structure  of  each  component  is  defined  in  terms  of  different  entity  types,  e.g., 
the  input  component  is  of  type  InputDevice.  Each  component  of  the  engine  has  a 
corresponding  entity  which  maintains  the  control  information  of  that  component.  For 
example  the  InputDeviceControl  maintains  the  control  information  of  the  InputDe- 
vice. The  control  information  contains  two  parts:  the  user  context  information  and 
the  system  context  information.  The  user  context  information  in  InputDeviceControl 
consists  of  the  engine  Jd  of  the  Engine  to  which  the  input  device  belongs,  the  state 
of  the  input  device,  the  fuelJevel,  the  input_signal,  and  the  signalj'ate  of  the  input 
device.  The  values  of  these  fields  are  determined  dynamically  at  run-time,  when  they 
are  generated  by  the  active  monitoring  rules.  The  description  of  system  context  in- 
formation has  been  given  before.  It  is  generated  and  maintained  by  the  system  and 
can  be  used  by  the  prototyper  for  analyzing  the  target  system.  We  notice  that  the 
monitor_rulel  and  the  monitor_rule2  are  responsible  for  generating  execution  context 
information  which  are  stored  as  the  instances  of  the  InputDeviceControl,  Processor- 
Control,  and  OutputDeviceControl  entities  referred  by  variables  icJnst,  pcJnst,  and 
ocJnst  respectively  in  rulel.  The  deductive  rules  are  state-based,  declarative,  and 
high-level  in  nature.  They  facilitate  the  prototyper  to  detect  the  presence  of  typical 
faults  and  defects  in  the  target  system  being  developed.  In  the  above  example,  we  see 
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that,  if  (1)  the  Processor  of  some  engine  reached  the  ON  state,  before  the  InputDe- 
vice  of  that  engine  could  reach  the  ON  state,  (2)  the  current  Processor  temperature 
of  that  engine  is  less  than  its  OutputDevice  temperature,  and  (3)  the  external  tem- 
perature of  the  OutputDevice  of  that  engine  is  greater  than  some  THRESHOLD 
value,  then  the  antecedent  part  of  rulel  will  be  evaluated  to  true.  The  consequent 
part  of  rulel  will  then  be  executed  to  generate  an  instance  of  the  ActualEngineS- 
tatus,  with  appropriate  field  values  as  specified  in  the  rule.  The  triggering  of  one 
deductive  rule  may  lead  to  the  triggering  of  other  deductive  rules,  if  their  antecedent 
clauses  are  evaluated  to  true.  In  the  above  example,  if  the  temperature  attribute 
of  the  ActualEngineStatus  instance  of  some  engine  happens  to  be  greater  than  the 
temperature  of  ExpectedEngineStatus  instance  for  that  engine,  then  the  antecedent 
of  rule2  will  be  evaluated  to  true,  and  this  will  result  in  the  generation  of  an  instance 
of  the  AffectedClient  entity.  The  value  of  the  ExpectedEngineStatus  instance  is  de- 
termined apriori  by  the  prototyper  based  on  his/her  knowledge  about  the  desired 
system  behavior.  The  deductive  rule,  rule2,  performs  the  job  of  behavior  analysis 
since  it  compares  the  actual  and  the  expected  system  behavior  pointing  out  the  caller 
that  has  been  affected.  Whereas,  rulel  performs  behavior  abstraction  since  it  infers 
high-level  information  about  the  status  of  the  engine  from  the  low-level  interaction 
information  of  its  components  with  its  caller,  and  the  state  information  of  different 
components  of  the  engine.  The  generation  of  instances  in  the  consequent  part  of  the 
rule,  may  again  lead  to  the  triggering  of  other  rules  in  those  classes  to  carry  out  more 
inferencing.  Thus,  we  see  that  deductive  rules  can  be  effectively  used  to  detect  defects 
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in  the  target  system,  locate  sources  of  problems,  and  generate  feedback  control  use- 
ful for  understanding  the  behavior  of  the  target  system.  The  process  of  modification 
and  evaluation  continues  until  the  prototyper  is  satisfied  with  the  functionality  and 
performance  results  of  the  target  system.  The  deductive  rules  can  perform  a  wide 
range  of  functions.  Some  of  these  functions  are  listed  below: 

1)  Inferencing:  deduction  based  on  complex  execution  behavior  (functionality  and 
performance) . 

2)  Simulating  control  system:  extracting  execution  behavior  and  accordingly  gen- 
erating the  feed-back. 

3)  Verifying  functional  correctness:  e.g.,  verifying  properties  about  input  to  out- 
put transformation,  the  state  at  the  point  of  interaction,  and  termination  of  a 
method. 

4)  Detecting  performance  bottlenecks:  e.g.,  detecting  which  method  took  the  max- 
imum time  to  execute,  and  performing  deduction  based  on  the  performance 
information.  For  example,  if  two  methods  have  the  same  functionality,  then 
one  with  better  performance  characteristic  will  be  chosen  for  execution.  This 
decision  can  be  derived  by  a  deductive  rule  at  run-time.  This  will  improve  the 
system  performance. 

7.2     Behavior  Abstraction 

The  process  of  deducing  high-level  behavioral  information  from  low-level  behav- 
ioral information  is  known  as  behavior  abstraction.  This  concept  can  be  illustrated 
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by  the  following  scenario.  Suppose  component  X  is  waiting  for  a  resource  of  compo- 
nent Y  and  component  Y  is  waiting  for  a  resource  of  component  Z  and  component 
Z  is  waiting  for  a  resource  of  component  X,  then  this  gives  rise  to  a  cyclic  wait-for 
condition  known  as  deadlock.  The  fact  that  one  component  is  waiting  for  the  other 
component  represents  a  piece  of  low-level  behavioral  information,  while  the  deadlock 
scenario  represents  a  high-level  behavioral  information  about  the  system.  Similarly, 
in  the  traditional  process  of  debugging,  it  is  the  developer's  responsibility  to  trace  the 
execution  of  a  program  and  keep  in  his/her  mind  all  the  low-level  interaction  informa- 
tion between  different  components  and  then  deduce  by  himself  the  high-level  behavior 
scenario.  Essentially,  by  using  monitoring  and  inferencing  rules,  we  automate  this 
process  of  behavior  abstraction  which  helps  the  prototyper  in  his/her  understanding 
of  the  behavior  of  the  target  system.  Monitor  rules  collect  the  low-level  interaction 
information  about  the  system  behavior,  which  consists  of  changes  to  the  states  of 
object  instances  and  interactions  between  different  object  instances.  Whereas,  the 
process  of  abstraction  is  carried  out  by  inferencing  rules.  In  the  previous  section, 
rulel  in  the  EngineSchema  illustrates  the  usage  of  state-based  deductive  rules  for 
behavior  abstraction. 

7.3     Behavior  Analvsis 

So  far,  we  have  shown  how  data  entities,  software  components,  method  imple- 
mentations, and  the  execution  context  information  can  be  modeled  uniformly  in  our 
object-oriented  model.  The  desired  system  properties  and  the  expected  system  be- 
havior can  also  be  modeled  in  the  same  model  by  using  various  modeling  constructs. 
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We  can  model  the  expected  output  of  different  methods,  and  their  boundary  condi- 
tions, i.e.,  the  state  before  and  after  the  execution  of  certain  methods,  in  terms  of 
entity  classes.  The  expected  control  flow,  either  system  wide  or  within  a  method, 
and  the  dataflow  between  different  methods  and  classes  can  also  be  modeled  in  terms 
of  various  entity  classes  and  associations  supported  by  our  underlying  object  model. 
This  expected  behavioral  data  can  be  used  to  compare  with  the  actual  execution  data 
to  perform  behavior  analysis  of  the  target  system. 

System  behavior  are  captured  at  run-time  by  active  ECAA  monitor  rules  and 
are  used  by  deductive  rules  to  perform  abstractions,  thus  producing  high-level  data 
which  convey  more  meaningful  information  about  the  actual  system  behavior  at  run- 
time. These  high-level  execution  data  can  then  be  compared  with  the  expected 
behaviors,  which  are  also  specified  in  the  same  model,  to  analyze  the  deviation  of  the 
system  from  the  desired  behaviors.  The  behavior  analysis  can  be  facilitated  by  high- 
level  deductive  rule,  since  they  can  be  used  to  derive  which  expected  behavior  was 
observed  during  the  actual  system  execution  and  at  which  points  the  system  deviated 
from  the  expectations  of  the  prototyper.  Thus,  we  see  that  deductive  rules  can  be 
used  not  only  to  derive  more  meaningful  high-level  information  about  the  system 
behavior  but  also  to  carry  out  behavior  analysis  of  the  target  system,  provided  that 
the  prototyper  also  models  the  expected  behaviors  of  the  system  using  the  same 
object  model.  In  Section  7.1,  rule2  in  the  EngineSchema  illustrates  the  usage  of  the 
state-based  deductive  rules  for  behavior  analysis. 
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7.4     Implementation  of  Deductive  Rules 

The  inferencing/deductive  rules  consist  of  two  parts,  namely,  the  antecedent 
part  and  the  consequent  part.  If  the  antecedent  of  a  rule  is  evaluated  to  true,  then 

it  implies  that  the  consequent  part  is  also  true. 

rule  rl 
antecedent  (exists  a_inst:A(al  >  7,  a2  <  b_inst.b3)  and 

exists  b_inst:B(bl  <  9,  b2  >  a_inst.al)  and 

exists  C(c3  >  a_inst.a2,  c2  <  b_inst.bl) 

) 


consequent 


(D.(dl:=  aJnsLal,  d2:=bjnst.b3,  d3:=  5)); 


end; 


joiii\  condition: 
(C.c3  >  AB.A.a2  )  and 
(  C.c2  <  AB.B.bl  ) 


A,  6  are  sibling  nodes 
AB,  C  are  sibling  nodes 
A,B,C  are  alpha  nodes 
AB  is  a  beta  node 
ABC  is  a  PNodc 
D  is  a  consequent  node 

Note  :  there  could  be  multiple  consequent  nodes,  connected  to  the  PNode 


Figure  7.1.  Example  of  an  Inferencing  Rule  and  Its  Corresponding  Rete  Network 


The  antecedent  part  of  deductive  rules  is  evaluated  by  building  a  Rete  network 
[For82]  for  the  antecedent's  condition  expression.  The  leaf  nodes  represent  different 
fact  classes  appearing  in  the  rule  condition.  In  a  Rete  network,  the  terminal  leaf 
nodes  are  called  alpha  nodes  whereas  the  intermediate  nodes  are  called  beta  nodes. 


rule  A::addliistance_rl 
triggered  when  an  A  instance  is  created 

condition  (rl::Activenag  =  I)  I  check    to 

see  if  this  instance  satisfies  the  selection 
condition  of  alpha  node  A 

action 

insert  a  reference  to  this  instance  in  the  alpha  node  A 
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rule  A::addlnstance_rl_deactive 
triggered  when  an  A  instance  is  created 
condition  (rl::ActiveFlag  =  0)  I  check  to 

see  if  this  instance  satisfies  the  selection 
condition  of  alpha  node  A 
action 

insert  the  reference  of  this  A  instance  in  the 
List  of  A  References  in  rl_DeactivatePool 
end; 


rule  alphaA::addInstance_rl  //  this  rule  is  in  alpha  node  A 
triggered  when  a  new  reference  instance  is  inserted  in  alpha  node  A 


check  to  see  if  this  instance  satisfies  the  join  condition 

with  the  other  instances  of  the  alpha  node  B 

for  each  match  between  the  alpha  node  A  instance  and 

the  alpha  node  B  instance  insert  a  compound  reference  to 

the  beta  node  AB,  which  contains  a  reference  to  the  A  instance 

and  the  B  instance 


Figure  7.2.   Active  Rules  Triggering  the  Flow  of  tokens  through  the  Rete  Network 
from  a  Leaf  Node 

The  root  node  of  the  network  is  called  a  PNode.    An  example  of  a  Rete  network 

structure  is  shown  in  Figure  7.1.    Within  each  alpha  node,  we  store  references  to 

those  object  instances  that  satisfy  the  selection  condition  for  that  node.  In  each  beta 

node,  we  store  only  the  references  to  those  compound  instances  which  satisfy  the  join 

condition  of  the  child  alpha/beta  nodes.  Figure  7.1  explains  an  example  rule  and  the 

structure  of  the  Rete  network  corresponding  to  that  rule  condition.  Active  rules  are 

generated  for  each  class  which  appears  in  the  antecedent  part  of  the  deductive  rule. 

They  are  triggered  whenever  any  instance  of  that  class  is  created/updated/deleted.  In 

Figure  7.2  the  active  rules  addlnstance_rl  and  addlnstance.rl_deactive  are  generated 

for  class  A.  Whenever  an  instance  of  class  A  is  created,  if  the  deductive  rule  rl  is 

active,  then  only  addlnstance_rl  is  triggered  while  addlnstance-rl-deactive  is  skipped 

since  its  guard  evaluates  to  false.   But  if  the  rule  rl  is  deactivated,  only  the  active 
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rule  PNodeABC::addInstance_rl  //  this  rule  is  in  PNode  ABC 
triggered  when  an  instance  is  inserted  into  this  node 
action 

execute  the  consequent  function  for  the  rule  rl, 
which  creates  a  new  instance  of  Class  D  with 
appropriate  binding  as  specified  in  the  specifications 
of  the  rule  and  insert  a  reference  to  this  newly  created 
instance  of  class  D  into  the  consequent  node 
end; 

//  Note  when  the  object  instance  D  is  generated  as  a  result 
//  of  firing  the  rule  rl  other  deductive  rules  can  also  get  Tired 
//  as  a  chain  reaction. 

//  Also  in  case  object  instances  are  deleted  we  have  similar 

//  ECAA  rules  which  removes  the  instance  references  from  the 

//  terminal  alpha  nodes  to  the  PNode,  and  retraction  of  the 

//  derived  consequent  from  the  consequent  node. 

//  An  update  is  treated  by  a  delete  followed  by  an  insert 

Figure  7.3.  Active  Rules  Triggering  the  Execution  of  the  Consequent  of  an  Inferencing 
Rule 
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rule  addlnstance-rl-deactive  is  triggered.  The  active  rule  addlnstance_rl  is  skipped 
because  its  guard  condition  evaluates  to  false  in  this  case.  If  the  deductive  rule  rl  is 
active,  whenever  an  instance  of  class  A  is  created,  addlnstance_rl  is  triggered.  If  the 
newly  created  instance  satisfies  the  selection  condition  ("al  >  7")  corresponding  to 
the  class  A  specified  in  the  antecedent  of  rl,  then  a  reference  to  this  newly  created 
instance  is  inserted  into  the  alpha  node  A  of  the  Rete  network,  by  the  action  of 
rule  addlnstance_rl.  In  case  the  deductive  rule  rl  is  deactivated  and  the  above 
mentioned  selection  condition  is  true,  then  addlnstance-rl-deactive  is  fired  which 
inserts  a  reference  to  the  newly  created  A  instance  in  the  List  of  A  References  in 
the  rl-DeactivatePool  structure  shown  in  Figure  7.4.  Active  rule  addlnstancejl  is 
generated  in  the  alpha  node  A,  which  is  triggered  whenever  an  instance  is  inserted 
into  the  alpha  node  A.  This  rule  is  fired  if  the  newly  inserted  instance  satisfies  the 
join  condition  with  its  sibling  alpha  node  B  which,  according  to  the  deductive  rule 
specification,  is  "A.a2  <  B.b3  and  B.b2  >  A.al."  For  each  match  of  the  join  condition 
between  this  newly  inserted  instance  in  the  alpha  node  A  and  an  instance  of  the  alpha 
node  B,  a  compound  reference  instance  is  inserted  into  the  beta  node  AB.  It  makes 
reference  to  the  corresponding  A  and  B  instances.  Active  rules  are  also  generated  for 
the  beta  nodes.  They  serve  the  purpose  of  triggering  the  flow  of  token  through  the 
Rete  network.  Active  rule  addlnstance_rl,  which  is  generated  for  the  PNode  ABC 
as  shown  in  Figure  7.3,  is  triggered  when  an  instance  is  inserted  into  the  PNode. 
It  invokes  the  consequent  function  in  its  action  part,  which  creates  a  new  instance 
of  class  D  with  the  appropriate  bindings  as  specified  in  the  consequent  part  of  the 
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rule.  A  reference  to  the  newly  created  D  instance  is  stored  in  the  consequent  node 
D,  shown  in  Figure  7.1.  We  store  only  the  object  references  within  each  alpha  and 
beta  node  instead  of  storing  the  entire  instance.  Inferencing  rules  can  be  activated 
or  deactivated  at  will  by  the  prototyper.  Only  those  deductive  rules  that  are  active 
will  be  subject  to  the  condition  matching  at  any  point  in  time.  The  mechanism  to 
achieve  dynamic  activation  and  deactivation  is  as  follows.  Since  a  deductive  rule  is 
translated  into  a  set  of  active  ECAA  rules,  we  include  the  testing  of  an  active  flag 
for  each  rule  as  a  guard  in  its  guarded  condition  expression  during  the  translation 
process.  An  active  rule  can  thus  be  deactivated  dynamically  by  setting  its  active  flag 
to  zero  i.e.,  the  guards  of  the  associated  active  rules  will  be  evaluated  to  false.  So 
if  the  flags  of  all  the  active  rules  corresponding  to  a  deductive  rule  are  turned  off, 
the  deductive  rule  is  deactivated.  For  activating  an  inferencing  rule,  the  active  flags 
of  all  the  corresponding  active  rules  are  set  to  one;  i.e.,  the  guards  are  evaluated  to 
true.  The  guarded  expression  of  a  rule  was  discussed  in  detail  in  Chapter  4.  For 
each  deductive  rule  we  maintain  a  DeactivePool.  During  the  time  when  a  rule  is 
deactivated,  whenever  an  instance  of  a  class,  which  appears  in  the  antecedent  part 
of  the  rule,  is  inserted/updated,  a  reference  to  that  instance  is  stored  in  a  list  in 
the  DeactivePool,  if  it  satisfies  the  selection  conditions  specified  in  the  antecedent 
of  the  rule  (see  rule  A::addlnstance_rl-deactive  in  Figure  7.2).  Note  that  the  guard 
condition  of  the  rule  A::addlnstance  is  evaluated  to  false  when  rl  is  deactivated. 
Thus,  this  rule  is  skipped.  No  change  to  the  state  of  the  Rete  network  of  rl  occurs 
when  rl  is  deactivated.  See  Figure  7.4  for  the  details  of  the  DeactivePool  structure. 
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Any  deductive  rule  can  be  activated  or  deactivated  by  invoking  the  activate()  or  the 
deactivate()  method.  The  activate  method  in  Figure  7.5  sets  the  active  flag  of  the  rule 
to  1  and  inserts  all  the  references  to  the  instances  in  the  lists  of  the  DeactivatePool 
into  the  corresponding  alpha  nodes  of  the  Rete  network.  This  will  cause  the  system 
to  take  into  account  those  facts  which  occurred  while  the  rule  was  inactive.  Initially, 
whenever  a  rule  is  defined,  it  is  activated  by  default. 


rl_DeactivatePooI 


List  of  A 
References 


List  of  B 
References 


List  of  C 
References 


rl 


Aggregation->  { 

Rete  Networlt 

rl_DeactivatePool 

ActiveFlag 

}; 

metliods: 
activateO 

deactivateO 


Figure  7.4.  The  Deductive  Rule  Structure 


The  inferencing  rule  specification  discussed  in  Section  7.3  is  first  parsed  by  a 
parser  to  build  the  rule  tree.  The  rule  processor  then  processes  the  tree  to  generate  the 
ruleTable  and  the  fact  Table,  which  represents  the  intermediate  code.  The  factTable 


method  rl::activate() 

1.  set  the  ActiveFlag  to  1 

2.  for  each  element  in  the  List  of  A  references  do 

insert  the  reference  into  the  alpha  node  A 
of  the  Rete  network  for  rl,  by  calUng  its 

insert  function. 

3.  for  all  the  other  Ust  which  has  references  to 

B  and  C  respectively,  repeat  step  2  by  inserting  the 
reference  into  the  corresponding  alpha  node  of 
the  Rete  network  of  rule  rl. 
end: 


method  rl::deactivate() 

1.  reset  the  ActiveFlag  to  0. 
end; 

Figure  7.5.  Activate  /  Deactivate  Methods 
data  structure  is  shown  in  Figure  7.7  and  Figure  7.8,  and  the  ruleTable  data  structure 
is  shown  in  Figure  7.9  and  Figure  7.10.  The  fact  Table  data  structure  contains  all 
the  information  about  those  classes  which  are  present  in  the  antecedent  part  of  an 
inferencing  rule.  The  ruleTable  contains  all  the  information  about  inferencing  rules. 
It  is  made  up  of  ruleTableEntry  list,  in  which  each  list  element  contains  information 
about  all  the  fact  classes  in  the  antecedent  part  of  the  rule,  information  about  the 
consequent  part  of  the  rule,  and  the  predicates  appearing  in  the  antecedent  part  of  the 
rule.  The  ruleTable  and  the  factTable  represent  the  normalized  structures  generated 
from  the  rule  tree.  The  ruleTable  and  the  factTable  are  further  processed  to  build 
the  Rete  network  for  each  deductive  rule.  The  leaf  nodes  of  each  network  are  made  of 
a  fact  class,  while  the  root  is  called  a  PNode.  The  mechanism  by  which  the  instances 
are  populated  within  a  Rete  network  is  as  follows.  Whenever  an  instance  is  inserted 
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in  a  class  which  appears  as  an  antecedent  in  any  of  the  deductive  rules,  active  rules 
are  fired  to  check  which  of  the  selection  conditions  of  leaf  nodes  are  satisfied  by  that 
inserted  instance.  In  case  the  instance  just  inserted  satisfies  the  selection  condition  of 
a  leaf  node,  a  reference  to  this  instance  is  inserted  in  that  leaf  node.  This  function  is 
carried  out  by  an  ECAA  rule  which  is  triggered  by  the  insertion  of  a  new  instance  into 
the  class  that  appears  in  the  antecedent  of  a  deductive  rule.  Each  leaf  node  contains  a 
list  of  references  to  those  instances  that  satisfied  the  selection  condition  for  that  node. 
Whenever  an  instance  is  inserted  into  the  leaf  class,  the  system  would  try  to  match 
it  with  its  sibling  alpha/beta  node  to  see  if  it  satisfies  the  join  condition  (if  any)  with 
its  sibling  node.  If  it  satisfies  the  join  condition,  then  a  reference  instance  is  inserted 
into  the  corresponding  parent  beta  node.  This  reference  instance  contains  the  oids 
of  the  instances  of  the  child  nodes  that  satisfied  the  join  condition.  If  the  beta  node 
is  not  the  root  (PNode)  node  of  the  network,  then  the  system  would  try  to  match 
this  new  reference  instance  with  its  sibling  alpha  node  to  see  if  it  satisfies  the  join 
condition  (if  any)  with  its  sibling  node.  If  it  does,  then,  again,  a  reference  instance 
is  inserted  into  the  parent  beta  node.  This  process  continues  until  an  instance  is 
inserted  into  the  PNode.  Whenever  an  instance  gets  inserted  into  the  PNode,  the 
action  corresponding  to  the  consequent  part  of  the  rule  is  executed.  An  action  is  an 
execution  of  a  consequent  function.  The  consequent  part  of  the  rule  results  in  the 
generation  of  more  control  entity  instances.  The  reference  instance  inserted  into  the 
PNode,  which  caused  the  execution  of  this  function,  is  passed  as  a  parameter  to  the 
function.  This  helps  in  creating  control  entity  instances  with  the  appropriate  bindings 
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within  the  body  of  the  consequent  function.  For  example  the  assignment  "D.dl  := 
aJnst.al"  specified  in  the  consequent  part  of  rl,  where  aJnst  refers  to  a  class  A 
instance,  can  be  achieved  as  follows:  "D.dl  :=  ABCJ.AB.A.al,"  where  ABCJ  is  the 
reference  instance  inserted  into  the  PNode  ABC.  The  generation  of  these  instances 
may  trigger  the  firing  of  other  inferencing  rules.  In  case  of  deleting  an  instance,  a 
reference  to  the  deleted  instance  (if  any),  is  deleted  from  an  alpha  node  before  the 
actual  instance  is  deleted.  Also,  whenever  a  reference  instance  is  deleted  from  a  child 
node  in  a  Rete  network,  the  reference  instance  in  its  parent  node  (if  any),  which 
points  to  it,  is  also  deleted.  The  case  of  update  is  handled  as  a  deletion  followed  by 
an  insertion. 

If  an  antecedent  clause  has  a  temporal  operator  like  "Before,"  "After,"  "Be- 
tween" etc.,  the  alpha  node  in  the  Rete  network  corresponding  to  this  antecedent 
clause,  has  references  to  the  corresponding  instances  of  the  classes,  which  appear  as 
operands  of  the  temporal  operator.  In  Figure  7.6  we  see  that  the  alpha  node  has 
references  to  an  instance  of  class  A  as  well  as  an  instance  of  class  B  which  satisfies 
the  temporal  and  selection  constraints  as  shown  in  Figure  7.6.  If  A  and  B  occur  in 
more  than  one  clause  in  the  antecedent  of  the  same  rule,  then  in  order  to  distinguish 
the  two  corresponding  alpha  nodes  in  the  Rete  network  of  the  rule,  we  use  an  unique 
index.  The  index  value  is  an  integer  like  1,  2  etc.  In  the  above  case,  the  alpha  node 
will  be  AB_1_R  since  it  corresponds  to  the  first  clause  in  which  A  and  B  appears  in 
the  antecedent  of  rule  R.  The  propagation  of  tokens  through  the  Rete  network  takes 
place  by  the  generated  active  rules  as  explained  in  the  example  given  before. 
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Say  the  first  antecedent  clause  in  a  rule  R  is  as  follows: 

( (STARTTIME  (last  A).(id  =  5))  Before  (STARTTIME  (last  B).(id  =  7)) ) 

Then  the  leaf  Node  structure  in  the  Rete  Network  for  the  above  fact  is  as  follows: 


A_instance 


B_instance 


Such  that :  (  SystemContext$A_instance.time  <  SystemContext$B_instance.time 
and  A_instance  is  the  most  recent  instance  of  class  A  with  id  =  5 

and  B_instance  is  the  most  recent  instance  of  class  B  with  id  =  7 

Figure  7.6.  Temporal  Clause  in  the  Rule  Antecedent 


factTableEntry 


factlnfo 


char*    className; 

factlnfo*  fL; 

linkTable*  IT;  //aggregate  attributes 

int  isTemporal;  //  temporal/non-temporal  fact 

factTableEntry*  next; 

factTableEntry*  prev; 

//  the  fL  is  the  factlnfo  list  which  is  the 
//  information  of  different  fact  instances 
//  in  difl'erent  deductive  rules  in  which 
//  this  className  appears  as  antecedent 


char*  varName; 
char*  rul^ame; 

int  qualifier;    //  EXIST,  ALL,  FIRST,  LAST 
char*  mName;  //  select  condition  method 
char*  joinClass; 

temporalrefNode*  tNode;  //  non-null  in  case 
//  of  temporal  fact 


Figure  7.7.  The  factTableEntry  Structure 
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temporalRefNode(for  temporal  fact) 


int  tempOperator;  //  AFTER,  BEFORE, 
//  BETWEEN  etc. 


char*  classNameP]; 
factInfo»  fL; 


factTableEntry*  fEntryList; 


Figure  7.8.  The  factTable  Structure 


ruleTableEntry 


treeNode 


char*  ruleName; 
char*  ruleStr; 
char*  factNames; 

selectMethod*  sMList;  //select  conds. 
treeNode*  root;  //  root  of  Rete  Network 
consequentList*  cList; 
ruleTableEntry*  prev; 
ruleTableEntry*  next; 


char*  ruleName; 
char*  className; 

char*  joinClassName; 

char*  joinPred; 

char**  methodList;  // joinMethodQ, 

//  createlnst0,dellnst() 
treeNode*  leftNode; 

treeNode*  rightNode; 
treeNode*  parent; 


Figure  7.9.  The  ruleTableEntry  Structure 
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selectMethod 


char*  methodName; 
char*  selectCondition[3]; 
char*  temporalClasses[3]; 
char*  temporalJoinPred;  //before,  after, 
//  between  etc. 

selectMethod*  prev; 

selectMethod*  next; 

int  temporalFunc;  //  last,  flrst,  nth  etc. 

char*  temporalVarNames; 


Figure  7.10.  The  ruIeTable  Structure 


-u 
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CHAPTER  8 
KNOWLEDGE-BASED  PROTOTYPING  ENVIRONMENT 


8.1     Prototyping  Environment 

A  prototyping  language  needs  to  be  supplemented  with  a  prototyping  environ- 
ment for  successful  specification,  and  implementation  and  evaluation  of  a  software 
system.  We  have  developed  a  KBMS-supported  evolutionary  prototyping  system  to 
support  the  implementation  and  evaluation  of  complex  software  systems.  Using  this 
system,  the  prototyper  can  i)  define  a  prototype  system  in  terms  of  classes,  semantic 
associations,  knowledge  rules  and  methods,  and  ii)  define  complex  methods  in  terms 
of  code  block  classes,  and  control-flow  associations  and  rules.  The  prototyper  can  val- 
idate the  executable  specifications  through  trial  and  use,  and  feedback  mechanisms. 
He/she  can  not  only  check  the  functionality  of  each  system  component  but  also  eval- 
uate its  performance.  Thus,  a  complex  system  can  be  developed  incrementally  and 
rapidly.  In  this  methodology,  an  executable  model  of  an  evolutionary  prototype  is 
first  developed  by  using  the  prototyping  tools.  Then,  the  prototyping  tools  are  used 
to  test  the  performance  and  functionality  of  the  system  by  suppling  test  data  to  the 
executable  prototype.  If  the  performance  and  functionality  are  not  satisfactory,  then 
changes  are  made  to  the  prototype  until  it  meets  the  requirements.  The  prototype  is 
further  refined  and  enhanced  to  specify  the  finer  details.  At  each  stage  of  refinement, 
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the  evolving  prototype's  performance  and  functionality  are  evaluated.  This  iterative 
process  of  gradually  developing  and  testing  the  prototypes  continues  until  the  final 
target  system  is  developed.  Figure  8.1  shows  the  components  of  the  prototyping  en- 
vironment we  have  developed.  They  are  :  1)  Graphical  User  Interface,  2)  Prototype 
Analyzer,  3)  Program  Generator,  4)  K.3  compiler,  and  5)  KBMS.  The  GUI  contains  a 
number  of  tools  for  defining,  editing,  browsing  and  querying  the  models  of  prototypes 
stored  in  the  knowledge  base.  It  also  contains  tools  for  activating  the  Prototype  Ana- 
lyzer, the  K.3  Compiler,  and  the  Program  Generator.  The  prototyper  uses  the  GUI  to 
model  the  system  and  its  subcomponents  in  terms  of  object  classes  and  associations 
based  on  his/her  current  knowledge  of  their  structural  and  behavioral  properties  and 
constraints.  The  resulting  schema  represents  a  model  of  the  prototype  and  is  stored 
in  the  KB  (see  link  1  in  Figure  8.1).  As  he/she  gains  more  knowledge  of  the  require- 
ments and  functionalities  of  the  system,  the  schema  will  be  refined  and  decomposed 
to  capture  the  details  by  using  the  graphic  editor.  All  methods  of  the  classes  in 
the  schema  are  either  coded  or  modeled  using  the  alternatives  described  earlier  in 
this  dissertation.  At  each  stage  of  the  modeling  and  refinement  of  a  prototype,  it  is 
executed  and  tested  for  its  functionality  and  performance.  Before  its  execution,  the 
prototyper  can  provide  some  performance  and  debug  flags  to  the  Program  Generator, 
which  embeds  trace  code  and  calls  to  the  Performance  Monitor  and  the  Execution 
State  Monitor  into  the  model  of  a  specified  prototype  retrieved  from  the  KB  (see 
links  2  and  3  of  the  figure).  The  Program  Generator  produces  an  application  system 
code  in  K.3  with  the  embedded  trace  code  and  calls.  The  K.3  compiler  is  then  called 
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to  translate  the  K.3  code  into  executable  C++  code  (see  link  4).  It  uses  the  meta 
data  stored  in  KB  during  compilation  (i.e.,  the  compiler  is  driven  by  the  meta  model 
to  achieve  language  extensibility).  Before  executing  a  prototype,  the  prototyper  can 
also  provide  the  Prototype  Analyzer  with  some  test  data  and  breakpoint  information 
(link  5  of  the  figure)  for  testing  the  functionalities  of  the  whole  prototype  or  some 
selected  components.  At  run-time,  the  executable  prototype  makes  function  calls  to 
the  Functionality  Tracing  Monitor,  the  Performance  Monitor  and  the  Execution  State 
Monitor  (links  6,  7  and  8)  which  deposit  data  into  the  KB  or  present  performance 
and  debugging  results  to  the  prototyper  (link  9).  The  prototyper  can  also  use  the 
querying  tool  to  query  the  test  results  maintained  by  the  KBMS.  If  the  performance 
and  functionality  testing  fail  to  produce  satisfactory  results,  then  changes  are  made 
to  refine  and  enhance  the  prototype  (i.e.,  schema  modification)  using  the  GUI.  The 
new  prototype  is  again  tested  for  its  performance  and  functionality.  This  iterative 
process  of  modeling,  analysis  and  testing  of  the  evolving  prototypes  continues  until 
they  evolve  into  the  final  target  system.  The  approach  taken  in  this  work  provides  a 
way  of  revealing  design  misconceptions  and  errors  at  each  stage  of  evolution,  thus  re- 
ducing the  cost  and  time  of  software  development.  Complex  methods  are  modeled  by 
the  prototyper  through  the  GUI.  The  Program  Generator  converts  the  method  spec- 
ifications to  the  K.3  implementation  code  (see  Figure  4.2)  which  is  then  translated 
into  executable  C++  code  by  the  K.3  Compiler.  The  prototype  can  then  be  tested 
by  using  the  Prototype  Analyzer.  The  performance  and  functionality  testing  results 
are  stored  in  the  KB  by  the  Performance  Monitor  and  the  Functionality  Tracing 
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Program  Generator  Interface 


and  Performance  Testing 
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Function  Call      6 


Program 
Generator 


Applicalion  System  Code  (K) 
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Monitor  and  Execution  State 

Monitor       J^  4 


Persistent 

Data  Meu 


KBMS  (Queries,Rules,  and  Persistence  Support) 


Figure  8.1.  The  Evolutionary  Prototyping  System  Architecture 
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Monitor.  The  following  sections  discuss  the  different  components  of  the  prototyping 
system. 

8.2     Performance  and  Functional  Tracing  of  Prototypes  -' 

In  this  section  we  shall  describe  the  performance  and  functional  testing  processes 
in  detail  with  an  example.  Consider  the  following  schema  definition: 

define  zSchema   :   Schema 
end; 

define  zClass    :   Entity  in  zSchema 

methods    : 

public    ; 

method  mainO   where  {  method_model    :=  "MModelSchema"   }; 

method  set(a:    Integer, b: Integer)    :    Integer  where 

{method.model : =  "XModelSchema"} ; 
method  test(e: Integer.f: Integer) ; 


The  Prototype  Analyzer  supports  tracing  of  the  functionality  as  well  as  the 
performance  of  the  target  system  in  addition  to  running  the  application  as  shown 
by  the  main  menu  in  Figure  8.2.  Suppose  the  prototyper  is  interested  in  tracing 
the  functionality  of  the  method  named  set{)  of  the  class  named  zClass  in  the  schema 
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named  zSchema.  The  method  is  modeled  by  a  method  model  schema,  namely,  XMod- 
elSchema  whose  structure  is  shown  in  Figure  8.3.  In  this  case,  he/she  chooses  the 
functionality  tracing  option  and  specifies  a  breakpoint  which  consists  of  the  follow- 
ing set  of  parameters:  (schemaName,className,methodName,  optional  codeBlock- 
Name).  Figure  8.4  shows  the  state  diagram  of  the  functionality  tracing  process.  The 
nodes  represent  the  different  states  of  the  functionality  tracing  process.  The  arcs 
represent  transitions. 

Main  Menu(of  Prototype  Analyser  Environment) 


1.  Functionality  Tracing 

2.  Performance  Testing 

3.  Rtmning  Application 

4.  Exit  From  Environment 


The  details  of  options  1  and  2  are  described  in  details  In  separate  figure 

Figure  8.2.  The  Environment  Interface 


As  shown  in  the  sample  output  in  the  Appendix  B,  the  value  of  the  breakpoint  is 
(zSchema,zClass,set,X4).  The  prototyper  can  specify  multiple  breakpoints.  For  each 
execution,  an  executionID  is  associated  with  it.  The  prototyper  has  an  option  of 
either  specifying  the  executionID  himself,  or  it  is  assigned  by  the  prototyping  system 
automatically.  Then,  he/she  specifies  the  startpoint  of  the  execution  which  consists 
of  (schemaName,className,methodName).  In  the  sample  output,  the  startpoint  is 
(zSchema,zClass,set).    When  he/she  selects  a  startpoint,  the  system  automatically 
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prompts  him/her  to  enter  the  method  parameters  values  (if  any)  for  starting  the  exe- 
cution. After  the  breakpoints  and  the  startpoint  specification,  the  mode  of  execution 
has  to  be  specified.  The  environment  supports  two  modes  of  execution,  namely,  the 
step  mode  and  the  continuous  mode.  In  the  step  mode,  the  execution  is  halted  after 
executing  every  code-block  for  displaying  the  state  variables  of  the  program  visible 
at  that  point  of  execution.  The  prototyper  can  start  the  execution  from  that  point 
onwards,  either  in  the  step  mode  or  in  the  continuous  mode.  In  the  continuous  mode, 
the  execution  continues  until  a  breakpoint  is  encountered.  In  case  no  breakpoint  is 
encountered,  the  execution  continues  until  the  termination  of  the  program.  As  shown 
in  the  sample  output  given  in  Appendix  B,  the  prototyper  has  started  the  execution  in 
the  continuous  mode.  Thus,  the  execution  stops  after  processing  the  X4  code-block, 
where  the  breakpoint  was  set  initially. 

At  this  break-point  the  value  of  the  state  variables  (i.e.,  a  and  b,  which  are 
parameters  of  the  method  set(),  and  x  and  i,  which  are  defined  as  attributes  in 
the  method  model  schema  XModelSchema)  are  displayed.  After  tracing  through  a 
method,  if  the  prototyper  is  not  satisfied  with  the  functionality,  he/she  can  refine  his 
model  and  repeat  the  evaluation  process.  Besides  the  functionality  tracing  option, 
the  prototyper  can  check  the  performance  of  the  target  system.  As  shown  in  Figure 
8.5,  he/she  can  either  check  the  performance  of  a  method  or  a  code-block,  or  get 
the  execution  time  information  of  different  methods  and  code-blocks  in  a  particular 
execution.  This  performance  profile  data  will  help  him/her  to  determine  if  the  target 
system  has  met  the  performance  requirement.  If  not,  he/she  can  go  back  to  change 
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Figure  8.3.  A  Method  Model 
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his/her  model  until  the  desired  performance  requirement  is  met.  In  the  above  exam- 
ple, the  prototyper  is  interested  in  the  time  taken  to  execute  the  X2  code-block  in 
this  execution,  which  was  12985  micro  seconds,  as  shown  in  the  output  in  Appendix 
B. 


stale  Diagram  Representing  llie  Funlionality  Tracing  Process 


Figure  8.4.  The  Functionality  Tracing  Process 


The  Performance  data  is  collected  at  the  method  level  as  well  as  at  the  code- 
block  level.  Also  the  prototyper  can  get  statistics  reports  for  the  performance  profiles 
of  different  executions.  The  performance  data  is  modeled  using  the  same  object  model 
which  is  used  for  modeling  different  parts  of  the  software  system  described  in  Chapter 
4. 
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Stale  Dligrun  for  Perfomunce  Testing  erf  ■  Prototype 


Figure  8.5.  The  Performance  Evaluation  Process 


CHAPTER  9 
CONCLUSION  AND  FUTURE  WORK 


9.1     Conclusion 


In  this  dissertation,  we  have  presented  a  KBMS-based  evolutionary  prototyping 
methodology  and  its  supporting  KBMS  and  prototyping  language  K.3.  The  object 
model  of  the  KBMS  allows  data  entities,  software  components,  and  method  imple- 
mentations to  be  modeled  uniformly  by  their  structural  properties  in  terms  of  at- 
tributes and  associations,  behavioral  properties  in  terms  of  methods,  and  constraints 
in  terms  of  ECAA  rules  and  antecedent-consequent  rules.  A  prototype  of  a  complex 
software  system  is  initially  defined  by  a  schema  of  data  entities  and  software  compo- 
nents based  on  the  prototyper's  initial  knowledge  of  the  functional  and  performance 
requirements  of  the  system  being  developed.  The  schema  is  gradually  refined  and 
decomposed  as  the  prototyper  gains  more  and  more  knowledge  about  the  evolving 
prototypes  and  the  requirements  of  the  target  system.  At  each  stage  of  the  evolu- 
tion, the  prototype  is  executable  since  the  methods  of  all  object  classes  are  either 
implemented  by  real  code  or  simulated  code,  or  specified  by  method  models  which 
are  translatable  into  executable  code.  The  execution  of  a  prototype  allows  the  pro- 
totyper to  verify  if  it  satisfies  the  known  functional  and  performance  requirements 
and  to  make  further  modifications,  refinements,  and  extensions  until  the  final  system 
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is  constructed  and  tested.  Since  an  object-oriented  software  system  is  made  up  ob- 
jects which  interact  with  each  other  at  run-time  by  message  passing,  the  evaluation 
process  of  such  a  system  requires  the  following  steps.  First,  we  need  to  monitor  the 
different  inter-object  interactions  and  object  states  information  and  record  them  in 
a  persistent  store.  Then,  the  monitored  data,  which  represent  low-level  behavioral 
information,  need  to  be  further  processed  through  the  process  of  behavior  abstrac- 
tion to  derive  higher-level  information  that  are  more  meaningful  to  the  prototyper. 
Finally,  there  is  a  need  to  compare  the  actual  behavior  with  the  expected  system 
behavior  to  carry  out  the  behavior  analysis,  which  would  reveal  the  deficiencies  of 
the  system  and  pinpoint  the  locations  or  sources  of  problems.  In  this  dissertation, 
we  showed  how  event-based  ECAA  rules  can  be  used  to  monitor  the  inter-object 
interactions  and  object  states.  The  characteristics  of  ECAA  rules  make  them  very 
suitable  for  event  monitoring  and  data  recording.  We  have  shown  how  the  object 
model,  which  is  used  to  model  different  parts  of  an  application  system,  can  also  be 
used  to  model  the  control  information  that  capture  the  interactions  between  differ- 
ent objects  and  states  of  objects.  We  also  showed  how  state-based  deductive  rules 
can  be  used  to  support  the  processes  of  behavior  abstraction  and  behavior  analysis. 
Both  event-based  ECAA  rules  and  state-based  deductive  rules  are  useful  for  spec- 
ifying the  constraints  and  semantic  properties  of  the  system  under  development  as 
well  as  for  evaluating  its  functionality  and  performance.  In  our  implementation,  the 
state-based  deductive  rules  are  transformed  into  ECAA  rules  and  method,  which  are 
then  translated  into  executable  C-l— I-  code. 
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During  the  evolution  process,  the  KBMS  is  used  to  provide  querying,  persistent 
and  rule  processing  services  to  the  prototyper,  and  the  language  K.3  is  used  to  pro- 
vide programming  language  constructs  for  coding  methods  and  code-blocks,  and  the 
querying  constructs  for  retrieving  and  manipulating  the  knowledge  base. 

The  results  of  this  research  work  reported  in  this  dissertation  make  the  following 
contributions: 

1)  We  have  extended  the  underlying  object  model  of  a  knowledge  base  program- 
ming language  to  allow  the  modeling  of  complex  method  implementations  in 
terms  of  code-blocks  and  their  control  associations.  We  have  also  introduced 
high-level,  state-based  deductive  rules  in  addition  to  ECAA  rules  as  a  part  of 
specification  facility  of  the  object  model.  The  result  is  an  expressive  semantics- 
rich  object  model  capable  of  capturing  the  semantic  properties  and  constraints 
of  data  entities,  software  components  and  code-blocks  in  a  declarative  man- 
ner. Enriching  an  object  model  for  object-oriented  system  design,  analysis  and 
implementation  is  consistent  with  the  on-going  efforts  on  UML  [Uml98]  and 
CDL  [Cdl97]  of  the  standard  OMG  community.  The  programming  language  K 
with  the  extended  object  model  (i.e.  K.3)  can  serve  as  a  common  prototyping 
language. 

2)  We  have  introduced  an  object-oriented  system  design  and  development  method- 
ology, which  allows  a  complex  object-oriented  system  to  be  derived  through  a 
series  of  evolving  and  verifiable  prototypes.  The  methodology  is  based  on  the 
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use  of  a  knowledge  base  management  system,  which  provides  querying,  persis- 
tent and  rule  processing  support  for  data  collection,  system  monitoring,  behav- 
ior abstraction  and  analysis.  It  enables  the  prototyper  to  discover  design  errors 
and  misconceptions  at  early  stages  of  system  development.  A  complex  system 
can  thus  be  developed  more  correctly  and  quickly  through  the  evolutionary 
prototyping  process.  This  work  has  demonstrated  that  active  data/knowledge 
management  concepts  and  techniques  introduced  by  the  database  community 
can  be  applied  to  benefit  and  speed  up  the  software  development  process. 

3)  We  have  introduced  a  monitoring  mechanism,  which  makes  use  of  active  ECAA 
rules,  to  monitor  the  interactions  of  software  components  to  trigger  the  record- 
ing of  control  information  useful  for  evaluating  the  functionalities  and  perfor- 
mance of  a  software  system  under  development.  ECAA  rules  provide  not  only 
the  means  of  specifying  constraints  associated  with  data  entities  and  software 
modules  but  also  the  mechanism  for  monitoring  run-time  events  and  recording 
system  states. 

4)  We  have  demonstrated  that  state-based  production  rules  can  be  used  for  be- 
havior abstraction  and  analysis.  We  further  showed  that  this  type  of  rules  can 
be  translated  into  ECAA  rules,  which  are  more  procedure-oriented  and  suit- 
able for  code  generation.  In  this  work,  we  have  combined  both  types  of  rules 
to  facilitate  the  prototyping  effort. 
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5)  The  KBMS-based  evolutionary  prototyping  methodology  has  been  verified  by 
an  actual  implementation  of  the  common  prototyping  language  K.3,  the  KBMS 
with  its  extended  model,  and  the  prototyping  environment. 

In  addition  to  the  above  specific  technical  contributions,  we  believe  that  a  gen- 
eral contribution  made  in  this  work  is  to  the  field  of  Software  Engineering  by  showing 
how  active  knowledge  base  management  technology  and  rule  processing  techniques 
can  be  used  in  modeling,  implementation,  evaluation  and  maintenance  of  object- 
oriented  software  systems. 

9.2     Future  Work 

Although  the  implementation  effort  carried  out  is  sufficient  to  validate  the  re- 
search concept,  methodology,  and  mechanisms  introduced  in  this  work,  it  is  by  no 
means  adequate  for  industrial  uses.  Better  GUI  needs  to  be  developed  to  ease  the 
tasks  of  the  prototyper  in  providing  test  data,  tracing  execution  paths,  analyzing 
monitored  data  and  modifying  modeled  prototypes.  Also,  the  performance  of  the 
KBMS  needs  to  be  improved. 


APPENDIX  A 
DEDUCTIVE  RULE  BNF 


d_rule_spec    :   DEDUCTIVE_RULE  qualif ied.name   optional_is 
ANTECEDENT  f act_expr_list 

CONSEQUENT  gen_f act_list     END    ' ; ' 


fact_expr_list    ;    fact_expr 

I 

fact_expr_list  AND  fact_expr 


fact_expr  : 
non_temporal_fact 
I 
temporal_fact 


temporal_fact  : 

'('  time_of_fact  BEFORE  time_of_fact  ■)' 
I 

'('  time_of_fact  AFTER  time.of .fact  ')' 
I 

'('  time_of_fact  BETWEEN  time_of_fact  AND  time_of_fact  ')' 
I 

'('  temporal_projection  OPER  temporal_projection  ')' 
I 
'('  EXIST  temporal_basis_fact  ')' 
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time_of_fact  : 

'STARTTIME'  '('  temporal_basis_fact  ')' 
I 

'ENDTIME'  '('  temporal_basis_fact  ')' 
I 

'INTERVAL'  '('  temporal_basis_fact  ')' 

temporal_projection  :  '('  temporal_basis_fact  ')'  '.'  field_name 

noii_temporal_fact  :    '('  EXIST  class_name  optionaI_class_qual  ')' 
I 
'('  ALL  class_name  optional_class_qual  ')' 

temporal_basis_fact  :  '('  temporal_fvmc  class_instance_set  ')' 
optional_class_qual 

class_instaiice_set  :  class_naiiie  optional_class_qual 

temporal_func  :  FIRST  I  LAST   I  B.LAST  I  B_FIRST  I  number 

optional_class_qual  :  '.'  '('  boolean_expr_list  ')' 

boolean_expr_list  :  boolean_expr 

I  boolean_expr_list  ' , '  boolean_expr 

boolean_expr  :  Ihs  OPER  rhs 

Ihs  :  IDENTIFIER 

OPER:  OR  I  AND  I  LT  I  LE  I  GT  I  GE  I  EQ  I  NE  I  XOR 

rhs  :  temporal_projection 
I  terminal_value 

gen_fact_list  :  gen_fact 

I 

gen_fact_list  AND  gen_fact 

gen_fact  :  fact_class_name  optional_attr_info 

optionaI_attr_info  :  '.'  '('  assigninent_operation_list  ')' 


Ill 


assignment_operation_list  :  assignment_operation 

I  assignment_operation_list  ' , '  assignment_operation 


assignment_operation  :  Ihs  ';  =  '  rhs 

terminal_value  ; 
INTEGER 
REAL 
STRING 
variable 

IDENTIFIER  ' . '  IDENTIFIER 
IDENTIFIER 


number         :  INTEGER 


APPENDIX  B 
RESULTS  OF  EXECUTION  TRACING 


dolphin :  102  '/,  krun  envPrg 

if  you  want  to  do  functionality  testing        press  1 
if  you  want  to  do  performance  testing  press  2 

if  you  want  to  do  run  your  application  press  3 

if  you  want  to  do  quit  from  the  environment     press  4 

1 
would  you  choose  execution  Id(yes/no) 

yes 
enter  execution  Id  (an  Integer  ) 

1 
do  you  want  to  set  another  breakpoint 
yes 

enter  breakpoint  schema  Name 
zSchema 

enter  breakpoint  class  Name 
zClass 

enter  breakpoint  method  Name 
set 

enter  breakpoint  CB  Name 

Press  Return  Only  if  fimctionality  done  in  the  Method  Level 
X4 

do  you  want  to  set  another  breakpoint 
no 

do  you  want  to  continue  functionality  testing 
yes 

enter  start  class  Name 
zClass 

enter  start  method  Name 
set 
enter  value  of  a 

1 
enter  value  of  b 

2 
enter  command  name(step/cont) 
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cont 

the  value  of  a  is  :  1 

the  value  of  b  is  :  2 

the  value  of  x  is  :  6 

the  value  of  i  is  :  3 

do  you  want  to  set  another  breakpoint 

no 

enter  the  next  command  (step  I  cont) 

cont 

do  you  want  to  continue  functionality  testing 

no 

if  you  want  to  do  functionality  testing        press  1 

if  you  want  to  do  performance  testing  press  2 

if  you  want  to  do  run  your  application  press  3 

if  you  want  to  do  quit  from  the  environment  press  4 

2 
for  Statistics  press  0 

for  performance  testing  of  a  method  press  1 
for  performance  testing  of  a  CB     press  2 
2 
enter  the  schema  Name 

zSchema 
enter  the  class  Name 

zClass 
enter  the  method  Name 

set 
enter  the  CB     Name 

X2 
enter  the  execution  Id 

1 

the  time  to  execute  this  CB  is  12985  micro  seconds 
if  you  want  to  do  functionality  testing         press  1 
if  you  want  to  do  performance  testing  press  2 

if  you  want  to  do  run  your  application         press  3 
if  you  want  to  do  quit  from  the  environment  press  4 

2 
for  Statistics  press  0 

for  performance  testing  of  a  method  press  1 
for  performance  testing  of  a  CB     press  2 
1 
enter  the  schema  Name 

zSchema 
enter  the  class  Name 

zClass 
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enter  the  method  Name 

set 
enter  the  execution  Id 

1 

the  time  to  execute  this  method  is  60997  micro  seconds 
if  you  want  to  do  functionality  testing        press  1 
if  you  want  to  do  performamce  testing  press  2 

if  you  want  to  do  run  your  application         press  3 
if  you  want  to  do  quit  from  the  environment  press  4 

2 
for  Statistics  press  0 

for  performance  testing  of  a  method  press  1 
for  performance  testing  of  a  CB  press  2 
0 

enter  execution  Id 
1 

CodeBlockName 
XI 
X2 
Yl 
Y2 
X3 
XX 
Zl 
Z12 
X4 
X42 
XS 
X51 
X6 


Time  Taken  (micro  seconds) 

1842 

12985 

9277 

3708 

16349 

16108 

8263 

7845 

6173 

7286 

6681 

6440 

3241 

The  time  taken  to  execute  the  method  setO  is  :  60997  micro  seconds 
if  you  want  to  do  functionality  testing        press  1 
if  you  want  to  do  performance  testing  press  2 

if  you  want  to  do  run  your  application         press  3 
if  you  want  to  do  quit  from  the  environment  press  4 

4 
dolphin :  103  */. 
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